Runc-Related Leaky Vessels Threaten Container Security
Earlier this year, Synk identified four vulnerabilities in Kubernetes and Docker containers. Collectively, these vulnerabilities are called the “Leaky Vessels,” and they pose a high threat to containerized environments. They are:
- CVE-2024-21626: CVSS – High, 8.6
- CVE-2024-23651: CVSS – High, 8.7
- CVE-2024-23652: CVSS – Critical, 10
- CVE-2024-23653: CVSS – Critical, 9.8
The Leaky Vessels exist in runc, an open source container runtime used by Docker and Kubernetes. The vulnerabilities are mainly associated with the runc command-line tool and the BuildKit toolkit that converts source code to build artifacts. The Leaky Vessels enable container escapes, allowing an attacker to execute a malicious piece of code on the host machine and compromise the entire system.
The vulnerabilities can pose a high level of risk to containers. Exploiting them could grant unauthorized access to the host operating system, compromise sensitive data and facilitate the lateral movement of data in the large Kubernetes or cloud environment.
In this article, I will share an in-depth analysis of each vulnerability, its impacts and suggested mitigation strategies.
CVE-2024-21626
The most significant of the Leaky Vessels vulnerabilities remains CV-2024-21626, which allows an unauthorized party to gain file system access to the host operating system.
CVE-2024-21626 resides in runc, a crucial tool responsible for spawning containers. Because of an internal file descriptor leak in versions 1.1.11 and above, the attackers can easily gain access and manipulate the working directory (process.cwd) of a newly spawned container process.
Just like an unlocked door, the leak can leave the file descriptor open, offering attackers access to the host file system. It can also grant unauthorized access and potentially lead to container breakout.
However, the risk of this vulnerability can be reduced significantly by only using prebuilt images from reputable registries.
CVE-2024-21626 Technical Breakdown
This vulnerability occurs mainly from how runc handles the file descriptor during the process of container planning. During the build process on the machine while setting up the container’s working directory using the setcwd(2) command, the file descriptor linked to the container’s working directory remains open, even when the user sets it to O_CLOEXEC.
The open file descriptor becomes easily accessible to the container process if the path resolves to a particular directory on the existing host file system.
Vulnerability Assessment
Attackers leverage this vulnerability by manipulating the process.cwd value. In a malicious image attack, the image script adds the process.cwd to the leaked descriptor path. In the runc run attack, the attackers set the command-line arguments or environment variables that influence process.cwd during container creation.
- Malicious image: The attacker embeds a specially created container image that contains a script that attaches the
process.cwdto a path on the host file system that can be accessed through a leaked file descriptor. As soon as the image is executed, the container process gains access to the host, compromising the device. - Runc run command: Attackers with access to the host system can leverage the vulnerability by running a container using the
runc runcommand. By changing the environment variables and command-line arguments, they can force the container process into setting the working directory to a leaked file descriptor on the host. - Runc run exec command: This scenario can have a broader impact than the other conditions. By gaining knowledge about an administrative process called
runc run execwith the current working directory flag, the attacker can exchange the complete path with a symbolic link (symlink) to a leaked file descriptor. This can give the attacker access to the host file system.
Impact
Once the working directory of the container process is set to the leaked descriptor path, it can provide access to the host file system at that particular location. This gives the attacker read, write and execute privileges, depending on the leaked file descriptor’s permissions.
Mitigation
Upgrade runc to version 1.1.12 or later. This can address the vulnerability by closing the leaked file descriptor. Also, using a prebuilt image from a reputable registry can help lower the risk.
CVE-2024-23651
This vulnerability arises from a symlink race condition in Docker versions below 23.0.1. The problem occurs during the image build process within the container’s cache-mount mechanism, which is implemented in Buildkit versions 0.12.4 and below. By exploiting the symlink race condition, attackers can gain access to the files from the host system.
CVE-2024-23651 Technical Breakdown
While using the RUN --mount=type=cache directive in the Dockerfile, you may try to specify your source for the cache mount. This source is merely a directory on the host system used by the Docker daemon in the cache directory. The Docker mounts this directory at a particular location in the Docker image being built.
The vulnerability occurs when the race condition exploits the validation of the cache-mount source path. The attackers try to replace the source path with a symlink to a nonexistent directory. Once the exploit is successful, this can be mounted into the Docker image.
Vulnerability Assessment
Attackers exploit this issue mainly by causing the user to build two malicious images at once. This can be done through malicious methods including poisoning the registry and typosquatting. The build will mount a cache called X and create a directory called Y.
The second build will try to mount the cache in path X, which is located inside Y. After confirming that Y is a directory, the first build will override it with a symlink to a sensitive location. The second build also mounts the sensitive directory to the container file system.
Impact
A successful exploit allows the attackers to access and manipulate the files on the whole system. This can lead to privilege escalation, data exfiltration and various other malicious activities.
Mitigation
Upgrade to Docker version 23.0.1 or later. This can address the vulnerability by fixing the race condition in cache invalidation. Also, upgrade any instance of BuildKit to version 0.12.5 or later.
CVE-2024-23652
This vulnerability affects Buildkit versions 0.12.4 and lower. It allows the attacker to access and manipulate the temporary directories of the container used during image build phases to delete arbitrary files on the host system. The vulnerability is mainly exploited during malicious Dockerfile builds, but it can also impact other build systems.
CVE-2024-23652 Technical Breakdown
Buildkit mounts the directory directly from the host into the container file system during various phases of the image-building process. When the directories become empty, Buildkit tries to remove them automatically within the cleanup process.
The vulnerability lies in how it determines whether a directory is empty or not. It only checks for files within the directory, does not consider the potential mount points within it and deletes the mount points on the host.
Vulnerability Assessment
To execute this exploit, attackers craft a malicious Dockerfile. This file mounts a specific directory on the host system within the container file system. It then creates a strategically placed empty directory within the container, above the mount point in the hierarchy.
The attacker manipulates the files within the mounted directory during the cleanup process. Buildkit mistakenly deletes the host’s corresponding directory, even if it contains sensitive data.
Impact
This critical vulnerability allows an attacker to delete critical file systems and gain unauthorized access to sensitive data. It can also corrupt the entire image build, potentially disrupting software delivery pipelines.
Mitigation
Upgrade Buildkit to version 0.12.2 or later. This patches the vulnerability properly and addresses the empty directory check logic.
CVE-2024-23653
This vulnerability resides in Buildkit versions 0.12.5 and earlier. It mainly arises from improper entitlement checks within the interactive container API, which allow the customization and interaction of containers based on built images. The vulnerability allows attackers to leverage a specially crafted Dockerfile to exploit the entitlement checks and achieve container escape.
CVE-2024-23653 Technical Breakdown
The attacker creates a Dockerfile that uses container configuration commands such as USER and RUN. This configuration then triggers a particular code path within Buildkit’s interactive container API. This results in adequate entertainment checks that can allow the container to gain elevated privileges.
Vulnerability Assessment
If the attackers leverage the elevated privileges within the container, they can exploit existing misconfigurations and vulnerabilities to break out of the container and gain complete access to the host system.
Impact
This vulnerability can cause a potential container escape, providing attackers with unauthorized access to the host system’s data and resources. It can also lead to other malicious activities.
Mitigation
Upgrade the Buildkit installation to version 0.12.5 or later. The newer versions come with the necessary patches to address the vulnerability.
Beyond Patching
Patching your system is important, but it may not completely mitigate these vulnerabilities and safeguard your system. Advanced cloud security solutions like AccuKnox Zero Trust can prevent an exploit from occurring with continuous monitoring, real-time behavioral insights and more.
For example, here’s how using a hardening policy can prevent one of the Leaky Vessels, CVE-2024-23652, from being exploited.
In a successful attack, an arbitrary Dockerfile-defined target file inside the host file system will be deleted. As Buildkit is generally running with root privileges, this can allow the deletion of any file in the host file system.
With hardening policies in place, a process with root privileges cannot perform any operations other than read. If an anomalous event occurs, you will be alerted and can configure policy enforcement to trigger inline mitigation, such as the following, which uses AccuKnox powered by KubeArmor Kubernetes runtime security engine.
Hardening rules will also monitor other CVEs (e.g., CVE-2024-21626, CVE-2024-23651 and CVE-2024-23653) and, if the necessary conditions occur, generate an audit event on the cloud native application protection platform (CNAPP) interface. You can also change the policy as needed to perform inline mitigation until the systems are upgraded.
Conclusion
AccuKnox Zero Trust Cloud Security adds a layer of protection against Leaky Vessels in your environment. Auto-generated policies achieve the least-permissive posture in your containers to prevent container escapes like the Leaky Vessels by default, thus protecting your application from potential threats.
