runc process.cwd Container breakout vulnerability

Looking at Leaky Vessels CVE-2024-21626


Container breakout vulnerability: the basics

What is container breakout vulnerability (CVE-2024-21626)?

Containers are ideally sandboxed instances that are isolated from the underlying host. A "container breakout" vulnerability is one in which an attacker is able to gain unauthorized access to the host operating system from within the container and, in some cases, can allow a user to access sensitive data (credentials, customer info, etc.), modify the system, and launch further attacks, especially when the access gained is with superuser privileges.

About this lesson

In this lesson, we will look at a very specific container breakout vulnerability. A malicious Dockerfile, inherited Docker image (e.g FROM malicious), or Docker image, when built with ‘docker build’ or run with docker run respectively, can break out of the container environment to the host environment in most cases to achieve full root command execution on the host.

This container breakout vulnerability is severe and has the potential to cause damage to any underlying host infrastructure that is building containers.

This issue has been assigned the CVE-2024-21626.


Discovered by Snyk

Snyk security researcher Rory McNamara, with the Snyk Security Labs team, identified four vulnerabilities — dubbed "Leaky Vessels" — in core container infrastructure components that allow container escapes. An attacker could use these container escapes to gain unauthorized access to the underlying host operating system from within the container.

Container breakout vulnerability in action

You can setup a vulnerable docker file with the below content. It specifies the WORKDIR to /proc/self/fd/7. It will reveal the content from /etc/shadow file

FROM alpine
WORKDIR /proc/self/fd/7
RUN cd ../../../../../../ && grep demouser etc/shadow && touch SUCCESSFUL_EXPLOIT

Check out the video to see it in action.

Breaking out of the container!

Container breakout via docker build. What you see here is the exploitation of docker build to break out of the container and access the host filesystem via an arbitrary read (in this example, the host’s /etc/shadow file) and write (in this example, the creation of a DOCKER_BUILD_BREAKOUT file).

Container breakout Demo 1

Next, let's look at a container breakout via docker run. What you see here showcases how running a malicious Docker image based on the same vulnerability can similarly result in the breakout of the Docker container to the host OS.

Container breakout demo 2

Impacts of Container Breakout Vulnerability

This vulnerability depends on a malicious container running or building within a vulnerable infrastructure. Due to the nature of this vulnerability, detection is difficult and requires runtime for the most accurate detection. As our existing Snyk products don’t operate on the application runtime, we built two tools to make detecting this vulnerability feasible.

Container Breakout Vulnerability under the hood

Let’s take a deeper look at what happened. The vulnerability occurs due to the order of operations when applying the WORKDIR directive defined in the Dockerfile. WORKDIR defines the initial working directory of all processes created by the Dockerfile, such as those executed at build-time using the RUN directive and those executed at run-time using the CMD or ENTRYPOINT directives.

The provided directory is entered using chdir before specific privileged host directory file descriptors have been closed. It is possible to specify one of these privileged file descriptors via the /proc/self/fd/ directory as the argument to chdir, which causes the privileged file descriptor to remain accessible even after the file descriptor itself is closed during normal operations, prior to handoff to the Dockerfile defined command, either at build or runtime.

When performing the chdir for either a build-time RUN command, or a run-time CMD (or equivalent) based on the specified WORKDIR argument, the chdir happens by path before the various privileged directory file descriptors are closed by the parent process.

A WORKDIR path can use these open file descriptors to chdir into a host directory, which can later be traversed out of to gain access to the host filesystem with the privileges of the Docker Engine. From here it is possible to break out of either the build-time or run-time environment to achieve full host compromise.

Scan your code & stay secure with Snyk - for FREE!

Did you know you can use Snyk for free to verify that your code
doesn't include this or other vulnerabilities?

Scan your code

Container breakout vulnerability mitigation

Because these vulnerabilities affect widely used low-level container engine components and container build tools, Snyk strongly recommends that users check for updates from container build and runtime vendors, including Docker, Kubernetes vendors, cloud container services, and open source communities. You should upgrade systems running container engines and container build tools as soon as fixes are released by your providers.

Install runc patch

We recommend that you take swift action by following the guidance provided in the runc advisory. The release of runc version 1.1.12 incorporates critical patches to address this security vulnerability. Additionally, it is crucial to update technologies bundling runc to their respective patched versions. 1 bug needs a runc update, the other 3 need a buildkit update.

Identify risks leveraging our runtime detection tools

To assist you in identifying potential risks, we have released two open-source tools to serve as reference implementations to help the community identify attempts to exploit these four vulnerabilities.

The Snyk team that recently joined us from Helios has built a runtime detection tool, leaky-vessels-dynamic-detector, for detecting these vulnerabilities based on full-stack runtime data collection technology. This standalone tool, released under the Apache-2.0 license, provides a reference implementation for detecting the vulnerabilities as they are executed.

The second tool is a static analysis program, leaky-vessels-static-detector, also released under the Apache-2.0 license, that scans Dockerfiles and image layers to detect commands that appear to be trying to exploit the vulnerabilities

Update container infrastructure

While updating your container infrastructure is our primary recommendation, we understand that immediate updates may not always be feasible. In such cases, our runtime detection tool can help you evaluate your risk and exposure in the near term. We strongly advise reaching out to your container infrastructure provider to confirm the status of their patched infrastructure.

Remediation should be done at the infrastructure and code tooling level. If applicable, look for announcements or releases from the provider or vendor of your container build and orchestration systems. You will likely need to update your Docker daemons and Kubernetes deployments and any container build tools you use in CI/CD pipelines, on build servers, and on your developers' workstations. It’s also important to screen existing containers using tools like the ones Snyk built to determine if your orchestration nodes or build infrastructure have already been impacted.