Escaping like a Rocket via rkt enter

Last week, a researcher disclosed three vulnerabilities in rkt, CVE-2019-10144, CVE-2019-10145, and CVE-2019-10147, that let an attacker escape the container. Rkt is an open source container runtime created by CoreOS in 2014.

Why it’s cool: This vuln trio allows attackers to gain root on the host machine from a rkt pod. rkt up to version 1.30.0 doesn’t isolate processes in containers that are run with rkt enter. You can think of rkt enter like docker exec for Docker containers, but sloppier — binaries executed from rkt enter are run as root.

As a result, an attacker with access to these pods running as root could replace /bin/bash (which specifies that scripts should always be run with bash) with a malicious program that could then mount the root directory of the host machine into the pod — giving the attacker root on the host.

Digging deeper: The issue with the rkt enter command is that there is no seccomp filtering or cgroup isolation being applied to the binary executed by it — giving access to any and all syscalls and not enforcing any limits on system resources the binary can access (memory, CPU, network, and IO). Think of this like creating a new business entity at your bank, and finding you can access all transactions and tap into all the other businesses’ funds, too.

Yes, but: The attacker needs to have root access in the pod already in order to overwrite binaries this way. This means they’d need to have an exploitable privilege escalation vulnerability on hand for the rkt pod itself before they could exploit rkt enter. And it isn’t like those grow on trees.

Further, according to a survey last year, rkt usage is around 12% of the market — making it absolutely dwarfed by Docker usage (83% of the market). Additionally, rkt development, based on GitHub activity, seems to have mostly stopped around the time RedHat acquired CoreOS last year (probably because RedHat already offers CRI-O and podman). So, it’s unclear how many organizations are actually using rkt today, which suggests the potential footprint of this vuln will be small.

The bottom line: There’s likely no reason to press the panic button on this one. If you’re an organization using rkt, RedHat unfortunately doesn’t have a plan for fixing these issues (though maybe some kind hearted contributor will create a patch). Therefore, we’d recommend avoiding usage of the rkt enter command. You should also probably switch to a consistently maintained container runtime like Docker, LXC, podman, or containerd.

The Capsule8 Labs team conducts offensive and defensive research to understand the threat landscape for modern infrastructure and to continuously improve Capsule8’s attack coverage.