Welcome

Docker and runC Vulnerabilities: A Deep Dive into CVE-2024–21626 and Its Counterparts

Introduction:

This blog delves into Docker and runC vulnerabilities, spotlighting CVE-2024–21626 and CVE-2024–23651 to CVE-2024–23653. It breaks down technical aspects, risks, and mitigation measures, stressing the need for prompt cybersecurity action. Docker, an integral part of containerization, streamlines application deployment by encapsulating code and dependencies. CVE-2024–21626 exposes runC, a vital Docker component, to unauthorized access risks. The vulnerabilities in Docker BuildKit (CVE-2024–23651 to CVE-2024–23653) pose integrity threats during image construction. The blog emphasizes best practices, urging caution with untrusted sources, and highlights affected entities, stressing the continual need for security vigilance in evolving containerized environments.

---

Overview:

A brief description of each flaw is as follows:

CVE-2024–21626 (CVSS score: 8.6) — A security vulnerability in runC has been discovered, which could potentially allow unauthorized access to the container by exploiting process.cwd and leaked file descriptors.
CVE-2024–23651 (CVSS score: 8.7) — A build-time race condition in BuildKit that could result in a container breakout.
CVE-2024–23652 (CVSS score: 10.0) — During the teardown of BuildKit's build-time container, arbitrary deletion may occur.
CVE-2024–23653 (CVSS score: 9.8) — A security vulnerability in BuildKit related to GRPC SecurityMode privileges, which can lead to potential container breakout during the build process.

In this article, we will examine each of these vulnerabilities in depth, discussing their technical aspects, the potential risks they present, and the measures undertaken by the tech community to mitigate them. Our primary goal is to offer a comprehensive insight into the effects of these vulnerabilities on Docker and runC, along with the recommended security practices for safeguarding containerized environments from these potential threats.

Comprehending runc and Docker BuildKit: Core Aspects of Containerization

Before we explore the vulnerabilities, it is essential to comprehend the roles of runc and Docker BuildKit, as they are key components of the containerization ecosystem.

What is runC?

RunC serves as an industry-standard container runtime, acting as the underlying technology utilized by Docker and other platforms for container execution. It is responsible for the creation and operation of containers in accordance with the Open Container Initiative (OCI) specification, offering a command-line interface for managing their lifecycle. Notably, RunC prioritizes simplicity, robustness, and portability, enabling it to efficiently run containers across diverse environments.

What is Docker BuildKit?

Docker BuildKit represents an advanced build engine tailored for Docker images. Its introduction aimed to enhance the performance, security, and usability of building Docker images, offering a more efficient method for constructing Docker containers. One of its key features includes efficient caching of Dockerfile commands, parallel execution of build steps, and isolation of build contexts. BuildKit excels in handling complex build requirements and large-scale applications, making it a preferred choice among developers looking to optimize their Docker workflows.

CVE-2024–21626: The runC Container Vulnerability

CVE-2024–21626 is notable for its effect on the runC component, a crucial aspect of numerous open-source container management systems. This security flaw enables an attacker to gain access to the host filesystem by exploiting leaked file descriptors in runC versions up to 1.1.11.

---

Technical aspects:

The core of CVE-2024-21626 can be attributed to a file descriptor leak in the runC package. This problem arises when running container code. Although users commonly configure file descriptors to close upon execution (O_CLOEXEC) to avoid leakage, a vulnerability exists in the way runC manages the setcwd(2) system call.

The unintentional action of runC is to retain an open file descriptor when establishing the present working directory. This vulnerability enables a container to retain a connection to this descriptor, particularly if the working directory is set as a path resolved through this leaked descriptor. The problem is further intensified by the fact that the non-dumpable bit, which provides a level of security by restricting other users from accessing the process's memory or state, is unset after execve. As a result, there are numerous avenues for potential attacks, extending beyond inadequately configured systems.

Implications

The consequences of this vulnerability are substantial. It has the potential to enable a container to break free from its designated boundaries and engage with the host's file system. This level of access could empower an attacker to view, alter, or erase system files, which could result in elevated privileges or additional exploitation of the host system.

CVE-2024–21626 attack vectors

Attack 1 — process.cwd “Mis-Configuration”: The attack method described here exploits the leaked file descriptor of a host's directory (such as /sys/fs/cgroup). By setting the working directory of a container to a specific path associated with this file descriptor, the attacker gains access to the entire filesystem of the host. This vulnerability can be taken advantage of by using a malicious image or Dockerfile.

Attack 2 — runc exec Container Breakout:Attack 1 can be modified by employing a different approach, wherein the attacker deceives either an administrative process or a user into utilizing runc exec with a specific --cwd argument that is associated with a leaked file descriptor. This method is more practical to execute since it necessitates less user engagement when compared to Attack 1.

Attacks 3a and 3b — Process.args Host Binary Overwrite Attack: These attacks involve overwriting host binaries by executing a path like /proc/self/fd/7/../../../bin/bash as the process.args binary argument in a container. This method allows an attacker to overwrite critical host binaries, facilitating full control over the host system.

Mitigation and Patching

To effectively protect against this vulnerability, it is crucial to close all unnecessary file descriptors prior to executing container code. This precautionary step necessitates careful configuration and ongoing maintenance of the container environment.
Action must be taken promptly to address this vulnerability. RunC has resolved this problem in version 1.1.12 by ensuring that the directory specified in the WORKDIR directive is located within the container's root filesystem. Additionally, privileged host directory file descriptors are now closed immediately after use. Updated versions that include these patches have been released by AWS, Ubuntu, and other prominent platforms.

CVE-2024–23651, CVE-2024–23652, and CVE-2024–23653: The Docker BuildKit Vulnerabilities

In addition to CVE-2024–21626, BuildKit has been found to have three more vulnerabilities, namely CVE-2024–23651, CVE-2024–23652, and CVE-2024–23653. These vulnerabilities impact versions up to 0.12.4.

The Nature of the BuildKit Vulnerabilities

BuildKit, a sophisticated build engine designed for Docker, encountered notable vulnerabilities in versions prior to 0.12.4. These vulnerabilities, specifically identified as CVE-2024–23651, CVE-2024–23652, and CVE-2024–23653, pose distinct yet interrelated risks during the process of constructing Docker images.

CVE-2024–23651 — Cache Mounts Race Condition: The race condition caused by shared cache mounts gives rise to this vulnerability. If two build steps are executed simultaneously and share cache mounts, it creates a possibility for files from the host system to be accessed by the build container. Exploiting this vulnerability is possible when a user tries to build a Dockerfile from a malicious project.

CVE-2024–23652 — Malicious BuildKit Frontend/Filesystem Tampering: The problem at hand pertains to a malevolent BuildKit frontend or Dockerfile that exploits the RUN --mount command to deceive the mountpoint removal feature. This could potentially lead to the removal of files located outside the container from the host system, thereby posing a substantial threat to the overall integrity of the host environment.

CVE-2024–23653 — Elevated Privilege Exploitation: This security flaw enables the utilization of BuildKit's APIs to execute containers with heightened privileges, circumventing standard security verifications. Unless specific security entitlements are activated, this vulnerability could be exploited.

Impact and Mitigation

The impact of these vulnerabilities is primarily on the integrity and security of the build process in Docker environments. They emphasize the need for strict security measures when managing containerization environments and the importance of auditing the source of Dockerfiles and build contexts. The planned fix for these vulnerabilities is in BuildKit version 0.12.5. Until these updates are applied, we advise users to exercise caution, especially when building from unknown sources.

Docker and runc container breakout vulnerabilities

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. Once an attacker gains access to the underlying host operating system, they could potentially access whatever data was on the system, including sensitive data (credentials, customer info, etc.), and launch further attacks. Upon discovery and verification, the Security Labs team initiated the process for responsible disclosure of the vulnerabilities, starting by notifying Docker, who, after review, forwarded one of the vulnerabilities to the open source runc security group. The disclosure timeline is below. 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.

Other Organizations Affected by These Vulnerabilities

Various organizations and systems were affected by CVE-2024–21626 and related vulnerabilities. Key affected entities include:
Cloud service providers such as AWS and Azure due to their extensive use of containerization technologies.
Companies that rely on Docker and Kubernetes for their operations.
Open-source projects and enterprises using container environments for development and deployment.
It is important that these and other organizations stay informed and take proactive measures to mitigate these vulnerabilities.

SMIIT Cyber AI can shield you from these very threats.

While Docker offers a great platform for development and deployment, recent vulnerabilities dubbed "Leaky Vessels" pose a significant security risk.
Proactive Vulnerability Detection: Our AI scans your container environment for known vulnerabilities, including "Leaky Vessels", keeping you informed and ahead of potential threats.
Automated Patch Management: We can automate the patching process for your containers, ensuring you have the latest security updates applied without manual intervention.
Continuous Monitoring: We continuously monitor your system for suspicious activities and potential breaches, allowing us to take swift action if needed.

---

Conclusion:

In conclusion, CVE-2024-21626 and related BuildKit vulnerabilities pose significant risks to containerized environments and impact various organizations and cloud service providers. These vulnerabilities highlight the need for vigilance and swift action in the cybersecurity community. The development of detection tools and patches reflects a proactive approach to mitigating these risks. It is critical for organizations to keep updated and apply the necessary patches while leveraging tools such as Snyk runtime detection and static analysis detectors for ongoing protection.

---