Mitigating Leaky Vessels Vulnerabilities in runc, BuildKit and Moby with Aqua

On January 31, 2024, researchers revealed the discovery of four severe security vulnerabilities in the container ecosystem. These vulnerabilities, affecting key components including runc, BuildKit, Moby (Docker Engine), and Docker Desktop, pose significant risks to the security and integrity of applications that use containerization applications.  

The vulnerabilities become exploitable in scenarios where a user interacts with malicious content, either knowingly or unknowingly. This can occur through various means, such as building Docker images from untrusted sources/Dockerfiles, falling victim to supply chain attacks, executing a container from dubious images/registries in the case of CVE-2024-21626 or other similar situations that could lead to successful exploitations, potentially resulting in full container escape and other behaviors.

In this blog we will explain the vulnerabilities, the implications, and how Aqua security can help you detect it.

At Aqua Security, we can reassure our customers and the wider community about the robustness of our security posture. A thorough review has confirmed that Aqua images are not susceptible to the vulnerabilities outlined, including the critical CVE-2024-21626. Although our images do incorporate runc libraries, these are categorized as indirect dependencies and thus do not present a vulnerability vector in our environment.

What is the impact of these vulnerabilities?

These vulnerabilities present various potential impacts, including full container escape, unauthorized access to the host filesystem, compromising the integrity of the build cache, and more.

What are the affected versions?

According to the Docker Security Advisory, the affected component versions and related patches are:

Besides this, some cloud providers such as Amazon Web Services (AWS) and Google Cloud have also issued alerts, urging their customers to take necessary actions wherever appropriate.

What is the Bottom Line to Mitigate these Vulnerabilities?

• Patch the vulnerable components with the latest available patched version (as shown in the table above).
• Only use trusted images, such as Docker Official Images, and avoid building container images from untrusted sources or untrusted Dockerfiles.

More information about additional mitigation methods and recommendations, if you cannot upgrade some components, can be found here 

Cloud Threats from These New Vulnerabilities

The recently disclosed vulnerabilities present a nuanced threat landscape, particularly affecting scenarios in which attackers gain control over container images, such as through supply chain attacks, or possess the authority to deploy new containers. Notably, one identified vulnerability, CVE-2024-23652, specifically enables the deletion of files with elevated privileges under conditions in which the attacker can engage in container build processes.

However, these vulnerabilities pose a limited risk in many cloud environments due to the specific prerequisites required for exploitation—namely, the capacity to execute or build malicious container images. Such prerequisites, while present in certain deployments, are relatively rare, thus mitigating the widespread impact of these vulnerabilities across diverse cloud platforms.

On the other hand, CVE-2024-21626 could certainly pose a threat if an attacker manages to persuade the victim to install their malicious image or create an image from a malicious Dockerfile designed to exploit this vulnerability.

The Leaky Vessel vulnerability can be exploited from the Dockerfile by manipulating the WORKDIR instruction. Specifically, an attacker can create a Dockerfile with a crafted WORKDIR instruction that points to the underlying host machine’s file system using /proc/self/fd/[ID], where [ID] is a system-dependent file descriptor.

Here’s how it can be used:

1. Craft a malicious Dockerfile with a manipulated WORKDIR instruction pointing to /proc/self/fd/[ID].
2. Build a container using the crafted Dockerfile.
3. Exploit the vulnerability to access sensitive files or execute arbitrary commands on the underlying host system.

By leveraging this vulnerability, an attacker can achieve full root remote code execution (RCE) on the host system, potentially compromising the entire Docker or Kubernetes host system.

Technical details

At the time of disclosure, four CVEs were disclosed:

• CVE-2024-21626 – runc process.cwd and leaked fds container breakout: involves leaked file descriptors in runc, allowing attackers to access or modify the host filesystem through crafted container processes. The vulnerability enables container escape potential when malicious images are run or built.
• CVE-2024-23651 – Buildkit mount cache race: Build-time race condition container breakout: highlights a race condition in BuildKit, where parallel build steps with shared cache mounts can expose host system files to build containers while building a malicious Dockerfile.
• CVE-2024-23653 – Buildkit GRPC SecurityMode privilege check: Build-time container breakout: is a high-severity vulnerability related to a missing privilege check in BuildKit’s GRPC endpoint. This issue arises when a custom syntax format allows for an alternative parsing container image to interact with BuildKit’s GRPC server. The vulnerability specifically lies in the handling of the Container.Start endpoint’s StartRequest.SecurityMode argument, which is not properly validated. This flaw enables the execution of build-time containers with elevated privileges, potentially leading to container escape and host root command execution during build of malicious Dockerfile.
• CVE-2024-23652 – Buildkit build-time container teardown arbitrary delete: exposes a flaw in BuildKit, where a BuildKit frontend or Dockerfile can misuse the RUN –mount feature by a malicious Dockerfile to delete host system files from within a container.

Aqua’s customers protected with our CNAPP Solutions

Aqua’s Cloud Native Application Platform (CNAPP) provides complete end-to-end protection for your cloud workloads. We comprehensively scan code, container images, and cloud workloads for known vulnerabilities, such as runc, hidden malware, embedded secrets, configuration issues, open source license issues, and more with the premium version of the award-winning cloud native security scanner Aqua Trivy. Our flexible acceptance gates are configured in the CI/CD pipeline, reducing the attack surface before deployment by allowing only authorized images to run. In production, our intelligence-driven runtime security controls ensure real-time protection of cloud native workloads. Runtime protection is critical to a holistic security strategy. In production, we ensure real-time protection of your cloud workloads with our intelligence-driven runtime controls that proactively alert the user if any unauthorized activity is detected. 

The following screenshots demonstrate how the Aqua Platform scans Dockerfiles for misconfigurations and detects the runc vulnerability in an EC2 instance when scanned using the premium version of Aqua Trivy and how the Aqua Enforcer (2022.4.461) detects any exploitation attempts in runtime.

Figure 1: Aqua’s Software Supply Chain Solution detecting the definition of WORKDIR /proc/self/fd/[ID]

Figure 2: Detection of the vulnerability in a running EC2 Instance

The runc vulnerability can also appear in container images which have dependency in the runc libraries, for example the runc Golang package. This is a popular use case for container images that are running images such as docker in docker images or images that are using runc API for different tasks.

Figure 3: Aqua Enforcer detects any exploitation activity in runtime.

Aqua’s behavioral detection signatures identify any exploitation attempts of the “Leaky Vessels” vulnerability in runtime and provide the user with a detailed alert and incident timeline for actionable remediation.