‘Leaky Vessels’ Docker Vulnerabilities Found in Many Cloud Environments: RunC (60%) and BuildKit (28%)

Originally published by Orca Security.

Written by Roi Nisimi.

On January 31st, Snyk unveiled the discovery of four novel container vulnerabilities that target the runC and BuildKit components within Docker container environments. The vulnerabilities were assigned CVEs with CVSS scores ranging from 8.6 to 10: CVE-2024-21626 in runC, and CVE-2024-23651, CVE-2024-23652, and CVE-2024-23653 in BuildKit. While no active exploits have been detected yet, these vulnerabilities pose a significant risk by potentially facilitating container escapes that could allow malicious actors to infiltrate and compromise the underlying container host system.

From our scans, we found that these high and critical severity vulnerabilities are widespread in cloud environments: 60% of organizations were found to be vulnerable to the CVE in runC, and 28% of organizations are vulnerable to the three CVEs in BuildKit.

To mitigate these risks, users are strongly advised to update their environments promptly. For self-managed environments, this entails upgrading to the latest versions of runC (version 1.1.12) and BuildKit (version 0.12.5). Alternatively, users can follow recommended guidelines, such as those provided by AWS, which advocate for updating ECS clusters to the latest AWS AMI or EKS cluster node groups to the latest AWS AMI. Taking proactive measures to address these vulnerabilities is paramount to ensuring the security and integrity of your containerized environments.

What are runC and BuildKit?

RunC is a container runtime implementing OCI standards, responsible for running container processes. BuildKit is a tool for efficiently building container images, offering features such as parallel execution and caching. Together, they power Docker’s containerization process, from image creation to container execution.

About The Leaky Vessels Vulnerabilities

Below we describe the four ‘Leaky Vessels’ vulnerabilities:

runC:

CVE-2024-21626 is a vulnerability with CVSS score 8.6 in the runC container runtime allowing an attacker to break out of the container isolation and achieve full root RCE via a crafted image that exploits an issue within the <mark>WORKDIR</mark> instruction’s handling. Since there’s a “race” condition between the time some file descriptors to the host are opened and closed, an attacker can create a Dockerfile with the following instruction WORKDIR /proc/self/fd/[ID] (with ID being a system dependent file descriptor) that will point to the underlying host machine’s file system.

BuildKit:

CVE-2024-23651 is a vulnerability in Docker with CVSS score 8.7 where a <mark>RUN</mark> command is using the –mount=type=cache flag. There’s a time-of-check/time-of-use (TOCTOU) vulnerability between the check that a source dir exists on the Docker daemon’s host and the actual call to the mount syscall. An attacker is able to craft a Dockerfile that would plant a symlink in between these two calls to induce an arbitrary bind mount that results in full root RCE on the host. This vulnerability only affects the docker build command.

CVE-2024-23652 is an arbitrary deletion vulnerability in Docker with a CVSS score of 10. When <mark>RUN --mount</mark> is used in a Dockerfile, if the target of the mount does not exist it will be created for that environment. When the execution completes, this created directory will be cleaned up. If the executing command changes the path used for the mount to a symbolic link, the cleanup procedure will traverse this symbolic link and potentially clean up arbitrary directories in the host root filesystem. This vulnerability only affects the docker build command.

CVE-2024-23653 is a vulnerability in Docker with a CVSS score of 9.8. The vulnerability occurs when using a custom Buildkit LLB generator with the <mark># syntax</mark> directive. The generator can use the Client.NewContainer and Container.Start GRPC calls to execute a new container during build. The StartRequest.SecurityMode argument is not appropriately checked against the privilege expectations of the docker daemon or docker build call, which allows the GRPC caller to create a privileged container during build. This new privileged container can then be escaped to gain full root RCE on the build host. This vulnerability only affects the docker build command.

How can hackers abuse these vulnerabilities?

As Snyk states, these vulnerabilities depend on a malicious container running or building within a vulnerable infrastructure. Hence, attackers can utilize these vulnerabilities by abusing the build / execution environment. For example, if an attacker can create a pod inside a k8s cluster, it can use a vulnerable image and thus achieve a container breakout.

A more overlooked way to exploit these vulnerabilities is through vulnerable base images. As Snyk states, when the Dockerfile refers to a base image via the FROM instruction that contains an ONBUILD command triggering the exploit e.e. ONBUILD WORKDIR /proc/self/fd/[ID]. The ONBUILD instruction injects the command not in the image that contains it but in the image that uses it as a base image. This means that if a base image is compromised or intentionally nefarious i.e. hosted on Dockerhub or other public container registries, exploitation if possible even if nothing changes in the image that the docker build command actually builds.

How To Remediate These Vulnerabilities

The main recommendation is to update any instances of runC to version 1.1.12 or later, as well as any software that depends on runC. BuildKit users should upgrade to version 0.12.5 or later. Make sure to follow the security advisories from AWS, GCP and Azure.

In addition, Snyk provides two open source projects for runtime detection and static analysis targeting the aforementioned vulnerabilities.