New vulnerabilities have been revealed in the runC command line tool (CVE-2024-21626) and in BuildKit (CVE-2024-23651, CVE-2024-23652, and CVE-2024-23653). These flaws pose a risk of container escape, meaning that exploiting them could grant unauthorized access to the host operating system, potentially compromising sensitive data and facilitating lateral movement in the larger Kubernetes or cloud environment.
The most significant flaw is CVE-2024-21626, enabling an unauthorized party to obtain filesystem access to the host OS, thereby gaining privileged control over the host. This flaw poses a significant threat to orchestration-based setups utilizing runC, such as Kubernetes. By exploiting this vulnerability, an attacker could execute a breakout onto the underlying Kubernetes node when deploying pods in a Kubernetes environment. The impact is heightened in multi-tenant clusters, where different tenants’ pods can share the same nodes. In such a scenario, a pod breakout could lead to unauthorized access to other pods containing data belonging to other tenants.
Moreover, this vulnerability extends its reach to impact build pipelines running in containerized environments, offering attackers an opportunity to establish a foothold within a build pipeline. This scenario could result in an attacker obtaining highly privileged credentials, granting access to critical production workloads or other sensitive environments.
Wiz customers can use Wiz to detect any vulnerable instances in their cloud environment and leverage the Wiz Security Graph to prioritize their remediation efforts. Wiz Runtime Sensor users can use the sensor to detect live exploitation attempts and additional related malicious activity.
What are the “Leaky Vessels” vulnerabilities?
CVE-2024-21626
As mentioned above, this is most impactful vulnerability, as it allows complete container escape under a multitude of conditions. In versions of runC up to v1.1.11, an attacker can exploit certain leaked file descriptors to access the host filesystem. This can be achieved by manipulating the working directory of a newly-spawned container process in an arbitrary container through runc exec or tricking a user into running a malicious container image, allowing a container process to reach the host filesystem via runc run. This may extend to overwriting host binaries, resulting in complete container escape.
It’s important to note that this vulnerability is also exploitable in higher-level runtimes like Docker or Kubernetes, either by running a specially crafted malicious container image (without additional configuration) or by specifying specific workdir options during container startup. Malicious Dockerfiles in the case of Docker are also relevant attack vectors for exploitation.
Exploiting CVE-2024-21626 from Docker Build Context:
An attacker creates a Dockerfile specifying the open file descriptor of /sys/fs/cgroup as the WORKDIR by using procfs (/proc/self/fd/[fd]). This manipulates the Docker build process, setting /sys/fs/cgroup from the host instance as the current directory of the child container.
FROM ubuntu
WORKDIR /proc/self/fd/[9] The attacker can then access the host's filesystem by traversing up a few levels and leverage the container's root access to read/write any file on the host:
RUN cd ../../../../../ && cat etc/shadowCVE-2024-23651
Within BuildKit versions up to v0.12.4, a race condition can occur when two malicious build steps run concurrently, sharing identical cache mounts with subpaths. This condition may result in files from the host system becoming writable to the build container, thereby allowing container escape. It’s important to note that this scenario arises only when a user attempts to build a specially crafted malicious Dockerfile.
CVE-2024-23652
Within BuildKit versions up to v0.12.4, a malicious BuildKit frontend or Dockerfile utilizing the RUN –mount feature could deceive the mechanism designed to eliminate empty files generated for mountpoints. This may inadvertently lead to the removal of a file outside the container, originating from the host system. Much like CVE-2024-23651, this vulnerability can only be exploited when a user employs a specially crafted malicious Dockerfile.
CVE-2024-23653
BuildKit offers APIs for launching interactive containers built from images. Typically, permission to run such containers is restricted unless the special security.insecure entitlement is activated in both the buildkitd configuration and approved by the user initiating the build request. In BuildKit versions up to v0.12.4, these APIs can be utilized to instruct BuildKit to run a container with elevated privileges.
Wiz Research data: what’s the risk to cloud environments?
According to Wiz data, at least 80% of cloud environments have instances vulnerable to CVE-2024-21626, with thousands of vulnerable resources in any given environment. Since this vulnerability does not require public exposure for exploitation, and can be exploited under many different circumstances, it is highly advised to patch as soon as possible.
Which products are affected?
CVE-2024-21626 affects instances running runC in versions before 1.1.12. Linux distributions are in the process of publishing patched versions to their impacted packages. As of February 4, 2024, the following Linux distributions have published an advisory for CVE-2024-21626: Debian, Ubuntu, Red Hat, openSUSE, AWS Linux and Alpine.
CVE-2024-23651, CVE-2024-23652, and CVE-2024-23653 impact BuildKit in versions before 0.12.5.
AWS released an advisory on January 31, 2024, for CVE-2024-21626, according to which no customer action is needed for AWS services, except for users of the following services: Amazon Linux, Bottlerocket OS, Amazon ECS, Amazon EKS, AWS Elastic Beanstalk, Finch, AWS Deep Learning AMI, AWS Batch and AWS Sagemaker. All listed services received patches that customers should install or were automatically updated to fixed versions with no customer action required.
GCP also released an advisory on January 31, 2024, according to which GKE is impacted by CVE-2024-21626, and they will release a patch once one is ready (as of February 5, 2023, a patch remains unavailable).
Azure has yet to publish an advisory on this subject as of February 5, 2023.
Who should be most concerned about this?
As we mentioned above, runc and BuildKit are incredibly prevalent in cloud environments, but not every system in the cloud affected by these vulnerabilities is equally exploitable:
First, organizations should prioritize patching virtual machines that serve as container hosts or container build systems. Exploiting this vulnerability by first having code execution privileges on a host and then launching a container only to achieve container escape back to the host is nonsensical and does nothing to improve the attacker’s posture.
Second, it is important to note that unlike most other known container escape vulnerabilities, exploiting these new vulnerabilities in Docker or Kubernetes environments depends on the attacker having control over any of the following:
Which container image (or pod) to run.
Which Dockerfile or BuildKit frontend is used to run or build a container.
How the container is launched (e.g., command line arguments).
Whether someone (in the target organization) will
runc execinto the container.
In other words, an attacker cannot necessarily exploit these vulnerabilities just by virtue of having code execution privileges in an arbitrary running container in an arbitrary environment. The container image itself, the corresponding Dockerfile or BuildKit frontend, or the command line arguments, must be specially crafted in advance to exploit these vulnerabilities at build or run time; or the attacker must anticipate a victim executing into the container while it’s running. We estimate the likelihood of the latter scenario is highly dependent on the operating model of the target organization and how long containers typically live in the target environment.
Based on the above, there are a few – albeit highly prevalent – scenarios in which these vulnerabilities are most likely be exploited, and if your organization is currently overwhelmed by vulnerability findings, we recommend prioritizing patching in the following cases before anything else (though we do recommend eventually patching all container hosts as a precautionary measure):
Use of runC to exec into publicly exposed containers – If an environment exposes containers to the Internet (e.g., by hosting a website), then an attacker might gain code execution within the container by exploiting a web or API vulnerability. If the same environment also has users or services utilizing
runc execas part of their day-to-day operations, then the attacker could set a trap that will trigger and exploit CVE-2024-21626 once someone execs into the container, thereby allowing the attacker to escape it. Note that this attack vector is possible regardless of the origin of the container. Environments in whichrunc execis in use should be patched as soon as possible, while prioritizing those hosting Internet-facing containers.Containers-as-a-Service – If your organization offers a service that allows customers to execute arbitrary code in a containerized environment, wherein users can provide their own images, Dockerfiles or BuildKit frontends for building or running containers, then this environment is at a very high and immediate risk of this vulnerability being exploited, and you should patch it immediately.
Anonymous write access to build pipelines – If your organization uses a container image build pipeline that allows anonymous access, then an attacker could modify Dockerfile or BuildKit frontends to include an exploit for these vulnerabilities, allowing them to gain code execution on the runner host building the image. Therefore, you should prioritize patching any such runners.
Use of 3rd-party container images – If your organization sources their images from any external registries or repositories (as many organizations do), then one of these images might turn out to be operated by a malicious actor who could insert an exploit for these vulnerabilities into a future version of the image. Alternatively, one of these images might be legitimate today but could one day be hijacked by a malicious actor, in which case they may enact a supply chain attack facilitated by these vulnerabilities against all organizations utilizing the image. Therefore, any container hosts known to run 3rd-party images should be prioritized for patching.
Susceptibility to image confusion – Within the previous scenario, if your organization accidentally imports an image using the wrong name (say, due to a typo in your Infrastructure-as-Code), you could fall prey to a typo-squatting attack, in which case you would ingest a malicious image that might include an exploit for these vulnerabilities. Similarly, if your organization’s pipeline is configured to always fetch the latest version of a container image, an attacker could set up a public container image using the same name as a private image you use, and under certain circumstances you might ingest the public malicious image by mistake. As best practice, organizations should harden their pipelines against this attack vector, but if this isn’t feasible, or if an organization cannot apply strict control over which container images they use, then all container hosts in the environment should be patched as soon as possible.
Use of container images from registries with anonymous write access – If your organization sources container images from a registry in which anyone from outside the organization can add or modify containers, then an attacker could hijack an existing image or add a new image and insert an exploit for these vulnerabilities, thereby gaining code execution on any container hosts running the malicious image. As best practice, organizations should harden their registries against anonymous access, but if they are unable to do so, they should immediately patch container hosts likely to run images from these registries.
Which actions should security teams take?
As mentioned above we recommend patching all container hosts in your environment in the near future, but we strongly advise prioritizing your efforts based on the guidelines provided in the previous section. Depending on the software you're using, these are the versions you should upgrade to:
CVE-2024-21626 has been patched in runC
v1.1.12.CVE-2024-23651, CVE-2024-23652 and CVE-2024-23653 have been patched in BuildKit
v0.12.5.All four vulnerabilities have been patched in Moby (Docker Engine)
v25.0.2and Docker Desktopv4.27.1.
As a general rule, only use container images from sources you trust, and only build container images from trusted Dockerfiles. Additionally, avoid using Buildkit frontends from untrusted sources.
Furthermore, the best long-term strategy to avoid being impacted by these vulnerabilities and any other container escape vulnerability is to employ defense-in-depth and never rely on containerization as a single security boundary, especially in multi-tenant environments. To learn more about how to safeguard your production environment against potential tenant isolation issues, refer to the PEACH framework.
Exploitation detection using the Wiz Runtime Sensor
Starting with sensor binary v1.0.3491 and definitions v1.0.848, the Wiz Runtime Sensor can detect live exploitation attempts of CVE-2024-21626. The Sensor should also detect stealthy exploit variants by focusing on the core of the vulnerability – the symbolic link traversal. As always, detection is performed while maintaining our promise of a minimal resource footprint and no negative impact on protected workloads.
For more information, Wiz customers can visit the Threat Center advisory for “Leaky Vessels”, which includes information on Runtime Sensor Detections.
Prevention using Wiz
Wiz customers can use the pre-built query and advisory in the Wiz Threat Center to search for vulnerable instances in their environment. We recommend focusing on affected virtual machines hosting containers, especially if their images are from external untrusted sources or from registries with anonymous write access (meaning that anyone could add or modify images in the registry). Wiz customers can also cross-reference these queries with other risk factors such as sensitive data findings on the affected host or lateral movement paths to K8s cluster admin.
