CVE-2019-5736 runc escape vs. SELinux

Hi All!

Two months ago, very interesting and dangerous CVE was published. It’s CVE-2019-5736 what is vulnerability in runc and allows malicious process in container to escape from container namespace and execute arbitrary code on host system with root privileges. For more information about vulnerability please see links in the end of this article. I would like to focus how SELinux blocking this exploit.

I used EOL release of Fedora 27, with docker where is bundled also vulnerable runc. I will use PoC and try to escape from container:

[root@enforced ~]# docker exec -it pwnme /bin/bash
[+] booted.
[+] opened ro /proc/self/exe <3>.
[+] constructed fdpath </proc/self/fd/3>
[+] bad_init is ready -- see </tmp/bad_init_log> for logs.
[*] dying to allow /proc/self/exe to be unused...

SELinux is in Enforcing mode, so SELinux security policy is Enforced by kernel:

SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      31

Let’s look what is in audit log:

[root@enforcing ~]# ausearch -m AVC -ts recent
type=AVC msg=audit(1554464510.001:479): avc:  denied  { write } for  pid=5190 comm="bad_init" name="docker-runc-current" dev="dm-0" ino=9162730 scontext=system_u:system_r:container_t:s0:c915,c946 tcon    text=system_u:object_r:container_runtime_exec_t:s0 tclass=file permissive=0

The output is saying that malicious process inside the container bad_init labeled as container_t tried to modify docker-runc-current labeled as container_runtime_exec_t on host system. This is clearly not good and should be blocked, what SELinux did.

Another great example why is clever to have SELinux in enforcing mode in your (not only) container environment. 🙂

Special thanks to Vincent Batts who helped me with vulnerable setup.