Another runc container breakout

Once again, runc—a tool for spawning and running OCI containers—is drawing attention due to a high severity container breakout attack. This vulnerability is interesting for several reasons: its potential for widespread impact, the continued difficulty in actually containing containers, the dangers of running containers as a privileged user, and the fact that this vulnerability is made possible in part by a response to a previous container breakout flaw in runc.

The runc utility is the most popular (but not only) implementation of the Open Container Initiative (OCI) container runtime specification and can be used to handle the low-level operations of running containers for container management and orchestration tools like Docker, Podman, Rancher, containerd, Kubernetes, and many others. Runc also has had its share of vulnerabilities, the most recent of which is CVE-2024-21626 — a flaw that could allow the attacker to completely escape the container and take control of the host system. The fix is shipped with runc 1.1.12, with versions 1.0.0-rc93 through 1.1.11 affected by the vulnerability. Distributors are backporting the fix and shipping updates as necessary.

Anatomy

The initial vulnerability was reported by Rory McNamara to Docker, with further research done by runc maintainers Li Fu Bang and Aleksa Sarai, who discovered other potential attacks. Since version 1.0.0-rc93, runc has left open ("leaked") a file descriptor to /sys/fs/cgroup in the host namespace that then shows up in /proc/self/fd within the container namespace. The reference can be kept alive, even after the host namespace file descriptors would usually be closed, by setting the container's working directory to the leaked file descriptor. This allows the container to have a working directory outside of the container itself, and gives full access to the host filesystem. The runc security advisory for the CVE describes several types of attacks that could take advantage of the vulnerability, all of which could allow an attacker to gain full control of the host system.

Mohit Gupta has an analysis of the flaw and reported it took about four attempts to successfully start a container with its working directory set to "/proc/self/fd/7/" in a scenario using "docker run" with a malicious Dockerfile. Because runc did not verify that the working directory is inside the container, processes inside the container can then access the host filesystem. For example, if an attacker is successful in guessing the right file descriptor and sets the working directory to "/proc/self/fd/7" they can run a command like "cat ../../../../etc/passwd" and get a list of all users on the system—more damaging options are also possible.

Sarai noted in the advisory that the exploit can be considered critical if using runtimes like Docker or Kubernetes "as it can be done remotely by anyone with the rights to start a container image (and can be exploited from within Dockerfiles using ONBUILD in the case of Docker)". On the Snyk blog, McNamara demonstrated how to exploit this using "docker build" or "docker run", and Gupta's analysis demonstrated how one might deploy an image into a Kubernetes cluster or use a malicious Dockerfile to compromise a CI/CD system via "docker build" or similar tools that depend on runc. What's worse, as McNamara wrote, is that "access privileges will be the same as that of the in-use containerization solution, such as Docker Engine or Kubernetes. Generally, this is the root user, and it is therefore, possible to escalate from disk access to achieve full host root command execution."

This isn't the first time runc has had this type of vulnerability, it also suffered a container breakout flaw (CVE-2019-5736) in February 2019. That issue led Sarai to work on openat2(), which was designed to place restrictions on the way that programs open a path that might be under the control of an attacker. It's somewhat amusing then, for some values of "amusing" anyway, that Sarai mentioned that "the switch to openat2(2) in runc was the cause of one of the fd leaks that made this issue exploitable in runc."

While this vulnerability has been addressed, Sarai also wrote that there's more work to be done to stop tactics related to keeping a handle to a magic link (such as /proc/self/exe) on the host open and then writing to it after the container has started. He noted that he has reworked the design in runc, but is still "playing around with prototypes at the moment".

Other OCI runtimes

While the vulnerability is confirmed for runc, the advisory contains a warning for other runtimes as well. Sarai writes, "several other container runtimes are either potentially vulnerable to similar attacks, or do not have sufficient protection against attacks of this nature." Sarai specifically talks about crun (a container runtime implemented in C, used by Podman by default), youki (a container runtime implemented in Rust), and LXC.

According to Sarai, none of the other runtimes leak useful file descriptors to their "runc init" counterparts—but he finds crun and youki wanting in terms of ensuring that all non-stdio files are closed and that the working directory for a container is inside the container. LXC also does not ensure that a working directory is inside the container. He suggests that maintainers of other runtimes peruse the patches for runc's leaked file descriptors. While these implementations are not exploitable ("as far as we can tell"), they have issues that could be addressed to prevent similar attacks in the future.

The good news is that, despite many container vulnerabilities over the years, so far we haven't seen reports of a widespread exploit of these flaws. Whether the credit belongs to the vigilance of container-runtime maintainers and security reporters, disciplined use of trusted container images, use of technologies like AppArmor and SELinux, the difficulty in using these flaws to conduct real-world attacks, or a combination of those is unclear. This shouldn't be taken to to suggest that those threats are not real, of course.

Note: you can avoid this step in the future by logging into your LWN account.