Unpatched vulnerabilities found in the rkt container runtime can be exploited by an attacker to escape the container and gain root access to the host. 

The flaws can be exploited to compromise the host when a user executes the ‘rkt enter’ command (which is the equivalent of ‘docker exec’) into an attacker-controlled pod, Yuval Avrahami, a security researcher at Twistlock, explains. 

An open source container runtime and a CNCF incubating project created by CoreOS, rkt is widely appreciated. The runtime’s basic unit of execution is a pod, which includes multiple containers running in a shared context, the researcher explains. 

At the moment, the project no longer appears to be under active development, following the acquisition of CoreOS by RedHat in mid-2018. Although an open source project, rkt does not appear to have many contributors. 

The ‘rkt enter’ command, the researcher notes, allows users to execute binaries in a running container. Such binaries run as root, with all capabilities and no seccomp filtering or cgroup isolation applied, being only restricted by namespaces. 

Because of that, it is possible to escape the container, and this is what the discovered vulnerabilities allow for, Avrahami explains. 

The flaws are tracked as CVE-2019-10144 (processes run with `rkt enter` are given all capabilities during stage 2), CVE-2019-10145 (processes run with `rkt enter` do not have seccomp filtering during stage 2), and CVE-2019-10147 (processes run with `rkt enter` are not limited by cgroups during stage 2). 

To exploit the bugs, an attacker requires root access to the container. Thus, when the user runs the ‘rkt enter’ command, the attacker can overwrite binaries and libraries in the container to ensure that the spawned process runs malicious code instead. 

For that, they need to overwrite /bin/bash and libc.so.6 in the container. These represent the default executed binary when none other was specified in the ‘rkt enter’ command, and the library likely to be loaded by the spawned process. 

“Once an attacker is running in the context of a container process spawned by ‘rkt enter’, he can escape the container and gain root access on the host with relative ease, as he runs with all capabilities, no seccomp filtering and without cgroup isolation,” the security researcher explains. 

One exploitation scenario involves mounting the host root directory using the ‘mknod’ and ‘mount’ syscalls, which would provide them with root access on the host. This attack also highlights the purpose of the isolation features lacking in the ‘rkt enter’ command.

The security researcher has published two videos to illustrate the three vulnerabilities and the aforementioned attack scenario. 

The security researcher has contacted RedHat and CoreOS to responsibly disclose these vulnerabilities, but was informed that RedHat had no active plan/timeline for addressing the issues. They instead encouraged Avrahami to post info on the bugs on GitHub, for the community to engage in any remediation operations.

“While investigating rkt I also discovered a way to create malicious ACI/OCI images that will compromise the host when run. Although this is certainly not ideal, malicious images are not a part of rkt’s threat module. Running images from an untrusted source is not aligned with rkt’s recommendations nor proper use,” the researcher notes. 

Related: Docker Vulnerability Gives Arbitrary File Access to Host

Related: No Root Password for 20% of Popular Docker Containers