Today researchers announced four new vulnerabilities in runC and BuildKit, which are popular and very widespread low level runtime environments. These vulnerabilities allow for container escape to the host operating system (OS), which means an attacker could gain full access to the host. The main recommended mitigations involve upgrading to runC version 1.1.12 and BuildKit version 0.12.5, which were both released today. To understand your exposure, KSOC’s open source Kubernetes Bill of Materials (KBOM) capability can help you find which container_runtime_version your cluster is running, and our runtime capabilities can help you find malicious containers running with these vulnerabilities.
What are runC and BuildKit?
Container runtime environments are critical elements in containerization, and are generally low level, abstracted away by Kubernetes or another higher level tool (like containerd, which you interact with via a CLI). The low level runtime environment, in conjunction with other build tools, automates the details of creating running containers from images.
In the case of runC, it is one of the more low level container runtimes, so users generally don't interact with runC directly, they interact with some other abstraction on top that then uses runC to execute commands. RunC works with other software, like BuildKit, to accomplish activities like unpacking the image layers and launching container processes, getting the file system in place, and cleaning up these processes and files once the container is deleted. In container runtime, BuildKit would be what builds the image, while runC does the actual execution of each step.
Underneath every running container in an application is a runtime environment, and runC is one of the most popular low-level runtime environments, created in 2015 by Docker and donated to the OCI, the Open Container Initiative (backed by the Linux Foundation).
How do CVE-2024-21626 and the other vulnerabilities work?
There were four vulnerabilities disclosed at the same time, related to runC and BuildKit.
CVE-2024-21626
In this vulnerability, an attacker could get a working directory in the host filesystem namespace by running a malicious image (or building an image using a malicious image). They would be able to do this because of an internal file descriptor leak within runC, including one relevant to the host, that occurs when process.cwd is set to /proc/self/fd/7/. In runC, process. cwd() returns the current working directory.
In summary, a malicious image, with the right configuration, could easily find a way to hide its usage of the triggering command and start a container (or trick someone else into starting one) whose binary has access to the host filesystem.
CVE-2024-23651
This vulnerability applies to BuildKit. This vulnerability depends on a certain condition at build time for mounting a cache volume. In BuildKit, cache volumes with a certain directive are able to mount a persistent directory at a controlled location during build. In this mount process, there is a place to specify a source path.
In the vulnerability, the source path can be replaced, allowing for an arbitrary mounting of a directory into the container filesystem. In essence, this creates a mount of the host root filesystem, with default root user access privileges that can control the host. This vulnerability would depend on an attacker’s ability to figure out what path the working directory is, which would require - -cwd (making a change to path in the container before executing a command).
The mitigation in version 0.12.5 of BuildKit ensures better validation of the source directory, with a file descriptor and source parameter.
CVE-2024-23652
This is a vulnerability in BuildKit as well, and would apply when building or using a malicious image. BuildKit can clean up temporarily added directories after use. When mounting files, the target directory for the mount can be created and removed afterward. In the vulnerability, if the overarching directory of the target directory is replaced with a symbolic link (while the container is alive), the removal operations for the temporary directory can be specified to act on any file in the host.
To fix this, BuildKit made sure that the location of the directory that is to be cleaned is located in the container filesystem, versus a link to another directory. This change was made starting in BuildKit version 0.12.5.
CVE-2024-23653
This is another vulnerability in BuildKit, in terms of its interaction with GRPC, which is a very common remote access framework. In build time, when an image is parsed for processing, you can submit custom parser format in place of the default. This is done by referring to another image which will create an intermediate parse output of the original image. The image that is doing the parsing for the custom format has access, in this process, to a GRPC server so that it can submit the intermediate parsing results. The endpoint in the GRPC server, that allows for the creation of new containers in build time, returns an argument that does not meet the BuildKit expectations and, and the vulnerability happens when the image that is doing the parsing for the custom parse format is able to launch an elevated container during build time based on the argument coming back from the GRPC server.
This was mitigated by defining that, if the argument comes back and is not in line with BuildKit’s expectations, the BuildKit daemon will not allow the creation of a privileged container, and is only present in BuildKit v0.12.5.
How likely are you to be affected, and what can you do?
RunC has recommended an update to version 1.1.12, though they did provide some potential workarounds for CVE-2024-21626. For the other CVEs involving BuildKit, the biggest recommendation is to upgrade to version 0.12.5 and detect your exposure in runtime.
But detecting where the vulnerabilities are located in your environment, and your exposure, due to the fact that these CVEs pertain to tools that work at runtime, container runtime security tools are most appropriate. This is true for all of the vulnerabilities.
In terms of their relative risk, the vulnerabilities that can happen without the introduction of malicious images, CVE-2024-23653 and CVE-2024-23651, are the easiest to take advantage of, and so are comparatively more likely to happen.
How KSOC can help
First, KSOC provides an open source Kubernetes Bill of Materials, KBOM, that can show you which container_runtime_version your cluster is running, to determine if your cluster is affected by this vulnerability. Running kbom generate will produce an output such as the following:
This vulnerability was patched as of containerd 1.6.28, so previous versions will hypothetically be vulnerable to this exploit. The cluster analyzed above, running 1.6.23, will be affected by this vulnerability.
KSOC customers can also detect these vulnerabilities with specific rules in runtime.
Reach out to the team to get help identifying your exposure to these high severity runtime vulnerabilities!
Request a Trial
