runc process.cwd Container breakout vulnerability

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.

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.

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

Check out the video to see it in action.

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).

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.

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.

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.

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.

To learn more about the vulnerability, check out some other great content:

• Leaky Vessels Container Breakout Vulnerabilities blog post
• runc process.cwd & leaked fds container breakout (CVE-2024-21626)
• Buildkit Mount Cache Race (CVE-2024-23651)
• Buildkit GRPC SecurityMode Privilege Check (CVE-2024-23653)
• Buildkit Build-time Container Teardown Arbitrary Delete (CVE-2024-23652)