Recently, Snyk announced the emergence of 4 new container vulnerabilities collectively dubbed “Leaky Vessels.” These vulnerabilities exploit the runC and BuiltKit components of Docker container environments. While the Snyk team discovered that there are currently no active exploits, these vulnerabilities allow for container escapes, enabling a malicious attacker to gain access to the container host system.

Users should upgrade to the latest versions of runC (1.1.12) and BuildKit (0.12.5) in self-managed environments or follow recommendations, for example, from AWS, to update their ECS clusters to the latest AWS AMI or their EKS cluster node groups to the latest AWS AMI.

Why are container breakouts problematic?

Container breakouts are problematic for the following reasons:

• Access to the host means you can extract any sensitive information on the host system such as secrets
• It gives you the ability to laterally move to other containers and perform more attacks

Our friends at Kubernetes GOAT talk about container breakouts in detail with steps on how to simulate this kind of attack.

What are runC and BuildKit?

RunC is the underlying low level container runtime technology that powers Docker, containerd and more. RunC fundamentally launches container processes, creates containers from images, and more. BuildKit, meanwhile, is the technology that actually builds the container image from a Dockerfile. BuildKit and runC work together to build the image and execute deployment of a container from an image, respectively.

Description of the vulnerabilities

runC:

CVE-2024-21626: This vulnerability is caused by a file descriptor leak within runC. The attacker can use a malicious image that adds a folder to keep access to the file descriptor and therefore add malicious files directly on the host with access to the host filesystem namespace and the ability to add and search for malicious content. In addition, using the run exec command a new container process can spawn a working directory in the host filesystem namespace.

BuildKit:

CVE-2024-23651: This one is caused by a race condition with mounting cache volumes. With the mounting process in BuildKit, you can specify a source path to mount a persistent directory. There is a race condition when two build steps running in parallel share the same cache mounts, allowing for a period of time/deadlock during which the directory can be changed to any arbitrary directory. For example, the host root file system can be mounted, leading to root privileges inside that can control the host and allow launching of malicious processes.

CVE-2024-23652: In BuildKit, directories temporarily added can be cleaned up. However, if a target directory for a mount that is meant to be removed is changed to a symlink, the removal operations for the temp directory can be used to remove any file in the host. This could mean that a malicious image could trick BuildKit to remove empty files outside the container, i.e., on the host, which of course is dangerous, leading to a host going down due to the deletion of system files, denial of service, or loss of data.

CVE-2024-23653: In this vulnerability, a malicious image can be used to start a privileged container in BuildKit. This is done by modifying a Dockerfile in such a way that the BuildKit security checks are bypassed. Running in privileged mode allows the container to get access to the host, which can lead to denial of service, as mentioned above.

How Uptycs can help:

• You will need to patch to the latest versions of BuildKit and runC as soon as possible. A platform like Uptycs can tell you which image layers are using these pieces of software, as well as which specific running containers have these vulnerabilities, by looking at the actual processes loaded into memory.
• Uptycs’ enhanced detection and response capabilities allow you to catch privilege escapes and use remediation actions to kill any container process that is running with these vulnerabilities.
• Leverage admission controls to block any images with these vulnerabilities from making their way into your container runtime. Both image policies and admission controls can be defined in Uptycs to prevent these issues from happening.
• Monitor your container runtimes on your clusters and upgrade to the latest AMIs/node images/container runtimes recommended by your cloud provider. In the Uptycs console, you can easily monitor your container runtimes across all clusters.