What Exactly is Leaky Vessels’ Vulnerabilities?
The Leaky Vessels’ vulnerabilities are all about container escapes—where an attacker can break out of a container and access the underlying host system. Usually, containers are supposed to be isolated, like separate ships on the same ocean. But with these vulnerabilities, the barriers get weak, and it’s like the containers start leaking.
Specifically, the issues with runC and BuildKit make it possible for someone to exploit these flaws and gain unauthorized access to the host OS. Once they’re in, they can do some serious damage, like stealing data, taking control of other containers, or even moving laterally across your entire network. This is why understanding and patching these vulnerabilities is critical.
What are runC and BuildKit?
To really understand the Leaky Vessels’ vulnerabilities, it’s important to know what runC and BuildKit are since they’re at the heart of this issue. So, what exactly are runC and BuildKit, and why do they matter in all of this?
RunC is a container runtime that’s responsible for actually running the containerized processes. It’s based on the Open Container Initiative (OCI) standards, meaning it’s pretty much the engine that powers your containers, making sure they start, stop, and stay isolated from each other and the host system.
But when a vulnerability like CVE-2024-21626 pops up, it means that runC isn’t doing its job properly, allowing attackers to break out of the container’s isolation and access the host system.
On the other hand, BuildKit is a tool used to build container images efficiently. It’s the behind-the-scenes workhorse that handles creating these images, using features like parallel execution and caching to speed things up. So when BuildKit has vulnerabilities, it can open the door for attackers to mess with your container images during the build process, which can have a ripple effect on your entire containerized environment.
Together, runC and BuildKit are essential to Docker’s containerization process—from creating the container image with BuildKit to running it with runC. But when they have vulnerabilities, like in the “Leaky Vessels” case, the whole process is at risk, and so is your infrastructure. That’s why it’s so important to understand and secure them—because they’re crucial to the entire container lifecycle, from image creation to execution.
Leaky Vessels’ Vulnerabilities: A Comprehensive Overview
Now that we’ve covered what runC and BuildKit are, let’s look into the specifics of the Leaky Vessels’ vulnerabilities that have been discovered in these tools. These flaws are particularly dangerous because they undermine the very security and isolation that containers are supposed to provide. Here’s a breakdown of the four key vulnerabilities:
1. runC: CVE-2024-21626
This vulnerability scores a high 8.6 on the CVSS scale and affects the runC container runtime. The issue arises from a race condition involving the handling of the WORKDIR instruction in a Dockerfile.
Specifically, an attacker can exploit this flaw by using a crafted Docker image that points to the host’s file system through a file descriptor. This effectively breaks the container’s isolation, allowing the attacker to gain full root access on the host machine. In practice, this means that if an attacker can run a container with a specially crafted image, they can potentially compromise the entire system.
Here is a quick overview of the vulnerability:
CVSS Score: 8.6 (High)
Impact: Container escape leading to full root RCE on the host
Exploit Method: Crafted image exploiting WORKDIR instruction handling
Technical Details:
- Exploits a race condition in file descriptor handling
- Attacker can use WORKDIR /proc/self/fd/[ID] in Dockerfile
- This can point to the host machine’s file system
2. BuildKit: CVE-2024-23651
This vulnerability, with a CVSS score of 8.7, affects the Docker build process when the –mount=type=cache flag is used in a RUN command. It’s a TOCTOU (Time-of-Check/Time-of-Use) vulnerability, where there’s a small window of time between checking if a source directory exists on the Docker daemon’s host and the actual mount syscall.
An attacker can craft a Docker file that plants a symlink between these two operations, leading to an arbitrary bind mount that results in full root RCE on the host. This vulnerability is particularly concerning because it targets the docker build command, a common operation in containerized environments.
Here is a rundown of the vulnerability:
CVSS Score: 8.7 (High)
Impact: Full root RCE on the host
Affected Command: docker build
Exploit Method: Crafted Dockerfile using RUN command with –mount=type=cache
Technical Details:
- Time-of-check/time-of-use (TOCTOU) vulnerability
- Attacker can plant a symlink between directory check and mount syscall
- Results in arbitrary bind mount
3. BuildKit: CVE-2024-23652
This one is critical of all, with a perfect CVSS score of 10 It’s an arbitrary deletion vulnerability that also affects the Docker build process. When using the RUN –mount command in a Dockerfile, if the target directory doesn’t exist, it’s created temporarily for the build process.
However, if an attacker manipulates the path to a symbolic link during execution, the cleanup process could mistakenly traverse this symlink and delete arbitrary directories on the host system. This flaw can result in significant damage to the host filesystem, making it a critical issue to address.
Heres a quick summary:
CVSS Score: 10 (Critical)
Impact: Arbitrary deletion in host root filesystem
Affected Command: docker build
Exploit Method: Manipulating RUN –mount target in Dockerfile
Technical Details:
- If mount target doesn’t exist, it’s created and later cleaned up
- Attacker can change the mount path to a symlink
- Cleanup process may follow this symlink, deleting arbitrary host directories
4. BuildKit: CVE-2024-23653
With a CVSS score of 9.8, this vulnerability occurs when using a custom BuildKit LLB generator with the # syntax directive. The vulnerability arises because the security mode of the container being started during the build isn’t properly checked against the expected privilege level.
This flaw allows an attacker to create a privileged container during the build process, which can then be escaped to gain full root RCE on the build host. Like the previous vulnerabilities, this one also targets the docker build command, making it a significant threat to any containerized environment relying on BuildKit.
Here is a quick overview of the vulnerability:
CVSS Score: 9.8 (Critical)
Impact: Full root RCE on the build host
Affected Command: docker build
Exploit Method: Custom Buildkit LLB generator with # syntax directive
Technical Details:
- Uses Client.NewContainer and Container.Start GRPC calls
- StartRequest.SecurityMode argument not properly checked
- Allows creation of privileged container during build
- Privileged container can be escaped for host access
These vulnerabilities all have one thing in common: they allow attackers to escape the container and access the host system, which can lead to major security breaches. If these flaws are exploited, it’s not just individual containers that are at risk, but potentially entire networks. It’s crucial to understand these vulnerabilities and apply the necessary patches to keep your containerized environments secure.
Which Products Are Affected by These Vulnerabilities?
Let’s get straight to the point. These vulnerabilities hit the core of modern containerized systems. Here’s the breakdown:
- runC: This is the container runtime that powers Docker, Kubernetes, and many others. If you’re running containers, there’s a high chance runC is involved. Outdated versions are directly vulnerable, making your entire container stack a target.
- BuildKit: BuildKit is the tool responsible for creating container images. It’s commonly used in Docker builds. Any pipeline relying on BuildKit without proper patching is exposed to potential exploits.
- Docker: Docker depends on both runC and BuildKit, so it’s affected on multiple levels. Systems using older versions of Docker Engine are particularly at risk, whether in production or development environments.
- Kubernetes: Kubernetes clusters utilizing vulnerable container runtimes are also impacted. This extends to managed services like GKE, EKS, and AKS. If you’re running workloads on Kubernetes, this needs immediate attention.
- Container Management Platforms: Tools built on Docker and Kubernetes—like OpenShift, Rancher, or similar platforms—are only as secure as their underlying runtimes. If these platforms haven’t applied patches, they remain vulnerable.
What You Need to Do
- Check your versions. Use runc –version or inspect the runtime and build tools in your CI/CD systems.
- Audit dependencies. Ensure any tools or platforms built on these technologies have applied the necessary fixes.
- Patch immediately. There’s no room for delay. Staying unpatched creates a direct path for attackers.
If you’re using these tools and haven’t updated, don’t assume safety. Verify and act fast.
How Hackers Exploit These Vulnerabilities
Hackers don’t leave vulnerabilities untouched—they act quickly, systematically, and with clear intent. Here’s what exploitation typically looks like:
Breaking Out of Containers
By targeting weaknesses in the container runtime, such as runC, attackers break free from the container’s sandbox. Once outside, they can manipulate the host machine and pivot to other systems within your network.
Gaining Administrative Access
Exploitation often involves privilege escalation. With this, attackers execute commands as an admin, bypassing restrictions and taking full control of the environment.
Compromising the Build Process
Flaws in BuildKit are a direct entry point for supply chain attacks. Hackers inject malicious code at the container image creation stage, embedding threats into every system that uses that image.
Spreading Laterally
Once inside your system, attackers don’t stop. They explore interconnected resources, accessing sensitive data, critical infrastructure, or other containers through lateral movement.
Data Theft and Manipulation
Exploitation often involves extracting sensitive information. Attackers target secrets, credentials, or API keys stored within containers or systems. This can lead to significant breaches and loss of trust.
Draining Resources
Some attacks aren’t just about data theft. Exploiting these vulnerabilities allows attackers to hijack your systems for cryptocurrency mining, slowing down operations and inflating operational costs.
The Bigger Picture
Every exploited vulnerability isn’t just a system failure—it’s a breach of trust. Attackers don’t just harm individual systems; they threaten the integrity of your entire operation.
What Needs to Happen Now
- Immediate Patching: Update all versions of runC, Docker, Kubernetes, and associated tools.
- Strict Permissions: Limit access and capabilities of containers to reduce the blast radius of an exploit.
- Advanced Monitoring: Track unusual patterns in container behavior and resource usage.
- Secured Configurations: Adopt industry-standard best practices to secure deployments and limit exposure.
Securing Your Container Environments: Actionable Steps
Now that we’ve covered what the Leaky Vessels’ vulnerabilities are and how attackers can exploit them, it’s time to focus on what really matters: fixing the problem. Here’s a direct, no-nonsense approach to securing your containerized environments against these vulnerabilities.
1. Apply Security Patches Immediately
Stop whatever else you’re doing and make sure your systems are patched. Both runC and BuildKit have released updates to address these vulnerabilities. Update to the latest versions immediately. Delaying this is asking for trouble.
2. Harden Your Build Pipelines
Your build pipeline is the foundation of your container strategy. Start by restricting the use of unverified base images. Validate all container images against known vulnerabilities using tools like Trivy or Aqua. Build security into the pipeline itself to ensure no unsafe operations sneak through.
3. Isolate Kubernetes Environments
Kubernetes clusters should have strict Role-Based Access Control (RBAC) policies. Lock down who can deploy containers and ensure each tenant operates in a tightly isolated namespace. Use Pod Security Policies (PSPs) to enforce minimum privilege containers and limit the risk of lateral movement.
4. Audit and Monitor Activity
Visibility is key. Implement logging and monitoring tools like Falco or Sysdig to detect unusual behavior in real-time. Look for signs of container escape attempts, unauthorized host access, or malicious builds. Auditing lets you respond faster, reducing the window of exposure.
5. Adopt Zero Trust Principles
Assume every container, every pipeline, and every node is a potential threat. Enforce strong authentication and minimize trust levels. For example, disable unnecessary container privileges and enforce network segmentation to contain potential breaches.
6. Leverage CSPM and CNAPP Solutions
Tools built for modern cloud security—like Cloud Security Posture Management (CSPM) or Cloud-Native Application Protection Platforms (CNAPP)—are your ally here. They help automate vulnerability scans, misconfiguration checks, and compliance enforcement.
Conclusion
These vulnerabilities are serious, but they’re manageable if you take swift action. Don’t wait for an attacker to expose the weaknesses in your containerized systems. Secure your build pipelines, isolate workloads, and adopt tools designed to combat threats like these. Staying ahead of the curve isn’t optional—it’s critical.
If you’re serious about securing your environment, the time to act is now.
