In the world of app sec, ASPM and container security, a new series of vulnerabilities affecting core container functionalities have been discovered: CVE-2024-21626, dubbed the “Leaky Vessels,” has emerged, casting a spotlight on the critical components of containerization technology—Docker, runs, and BuildKit. Together with the main vulnerability, other variations have been recorded all above 8.7 to the last one, a perfect 10: CVE-2024-23651, CVE-2024-23653, and CVE-2024-23652. These vulnerabilities underscore the ongoing challenge of vulnerability management within container ecosystems, serving as a crucial reminder of the importance of maintaining robust security practices in application development and deployment.
The CVE-2024-21626 “Leaky Vessels” Vulnerabilities Explained
At the heart of the “Leaky Vessels” vulnerabilities lies a significant flaw in runc, the underlying container runtime used by Docker and other container platforms, identified as CVE-2024-21626. This vulnerability allows attackers to gain unauthorized access to the host operating system from within a container, posing a severe risk to system integrity and data security. Alongside this, additional vulnerabilities in BuildKit—a toolkit for converting code into container images used in conjunction with runc—further exacerbate the threat landscape. These include CVE-2024-23651, CVE-2024-23653, and CVE-2024-23652, each presenting unique challenges in the context of container security.
Consequences and Impact CVE-2024-21626
The ramifications of these vulnerabilities are far-reaching. Attackers exploiting these flaws could potentially access sensitive data, manipulate system operations, or launch further attacks from the compromised system. The “Leaky Vessels” vulnerabilities serve as a stark reminder of the potential for significant downtime and data loss if not promptly and effectively addressed.
Chaining Vulnerabilities: A Closer Look
The interplay between the vulnerabilities in runc and BuildKit presents a complex scenario where an attacker could chain these vulnerabilities to escalate privileges and execute arbitrary code on the host system. This chain of vulnerabilities highlights the intricate dependencies within container runtime environments and the need for comprehensive security measures that span across different components of the container ecosystem.
Recently disclosed vulnerabilities, CVE-2024-21626 and others related to runC and BuildKit, highlight the ongoing challenges in securing containerized environments. Here’s a closer look at how these vulnerabilities function, offering insights into their mechanisms and implications.
Understanding CVE-2024-21626
CVE-2024-21626 exposes a critical flaw within the runC container runtime. This vulnerability arises from an internal file descriptor leak, specifically when the process.cwd is manipulated to access the host’s filesystem namespace. By running a malicious image or building one using a malicious base image, attackers can exploit this leak. The manipulation of process.cwd()—which returns the current working directory—to an unauthorized directory on the host, essentially grants the malicious container binary unfettered access to the host filesystem. This access enables a wide range of nefarious activities, from data theft to further system compromise.
The Mechanics of CVE-2024-23651 in BuildKit
CVE-2024-23651 targets BuildKit’s handling of cache volumes during the build process. This vulnerability leverages a specific condition related to the mounting of cache volumes, allowing attackers to mount a persistent directory at a controlled location. The crux of the issue lies in the manipulation of the source path, permitting an arbitrary directory from the host to be mounted into the container’s filesystem. This effectively grants default root user privileges over the host, contingent on the attacker deciphering the working directory path. Mitigation efforts in BuildKit version 0.12.5 have focused on enhancing the validation of the source directory to thwart such attacks.
Exploring CVE-2024-23652 and Its Implications
CVE-2024-23652, another vulnerability within BuildKit, emerges during the cleanup phase of temporarily added directories. The vulnerability is activated if the target directory for mounting files is altered with a symbolic link to another directory on the host. This allows attackers to specify removal operations for any file on the host, exploiting the cleanup process. The resolution in BuildKit version 0.12.5 ensures that the directory cleanup is strictly confined to the container’s filesystem, eliminating the risk of external manipulation.
CVE-2024-23653: GRPC Security Flaw in BuildKit
Lastly, CVE-2024-23653 highlights a vulnerability in BuildKit’s interaction with GRPC, a prevalent remote access framework. This issue arises during the build process when a custom parser format, substituted for the default, manipulates GRPC server interactions to launch containers with elevated privileges. The mitigation strategy involves the BuildKit daemon rejecting the creation of privileged containers if the returned arguments from the GRPC server deviate from expected parameters, a security enhancement incorporated from BuildKit v0.12.5 onwards.
Learning from the Past: Previous runc Vulnerabilities
This is not the first time runc has been in the spotlight for security vulnerabilities. Previous issues, such as the Runcscape vulnerability (CVE-2019-5736), have shed light on the potential for container escape and underscore the importance of ongoing vigilance and prompt updates to mitigate risks associated with container runtimes.
Addressing the Vulnerabilities
To safeguard against these vulnerabilities, it is imperative for organizations to prioritize security updates and patches from vendors. Docker and other tools utilizing runc and BuildKit have already released updates to address these issues. Additionally, inspecting Dockerfiles for unsafe commands and employing detection tools to identify potential exploits can further enhance security postures.
For more detailed insights and guidance on mitigating these vulnerabilities, refer to the expert analysis provided by Snyk and KSOC in their respective blogs:
- Snyk’s Deep Dive into Leaky Vessels Vulnerabilities
- KSOC’s Guide on Addressing Container Escape in runc and BuildKit
Red Hat advised inspecting Dockerfiles with the Run and WORKDIR directives to ensure they have no escapes or malicious paths. For those with Linux kernels supporting eBPF, Snyk has released a detector for the vulnerability, leaky-vessels-runtime-detector.
Get in control of your Application Security posture and Vulnerability management
Exploitation and analysis of CVE-2023-50164
No evidence of exploitation so far nonetheless, the major container house like AWS, Chainguard etc… are uploading clean images
PoC not found exploited in the wild: https://github.com/NitroCao/CVE-2024-21626
Several thread on X/ twitter are following the vulnerability and showing the exploit
How can ASPM Help
In the rapidly evolving field of application security, the ability to swiftly identify vulnerabilities across diverse environments, including containers and traditional virtual machines, is paramount. Advanced Security and Protection Mechanisms (ASPM) play a crucial role in this process by leveraging sophisticated scanning technologies and libraries designed for deep inspection. These mechanisms are engineered to detect vulnerabilities by analyzing the libraries and dependencies used within applications, regardless of the underlying infrastructure. ASPM tools integrate seamlessly with CI/CD pipelines, providing real-time feedback and ensuring that any security issues are identified at the earliest stage of development. Whether the application runs in a containerized environment, orchestrated by platforms like Docker or Kubernetes, or within a traditional virtual machine setup, ASPM facilitates a proactive approach to vulnerability management. This approach not only streamlines the security workflow but also significantly reduces the window of opportunity for attackers, enhancing the overall security posture of the application and protecting sensitive data from potential breaches.
Conclusion
The discovery of the “Leaky Vessels” vulnerabilities serves as a critical reminder of the inherent risks in containerized environments and the need for proactive vulnerability management and application security practices. By staying informed about potential vulnerabilities, applying timely updates, and employing comprehensive security strategies, organizations can navigate the choppy waters of container security and safeguard their applications against emerging threats.
How Phoenix Security Can Help
Phoenix Security ASPM helps organizations identify and trace which systems have vulnerabilities, understanding the relation between code and cloud. One of the significant challenges in securing applications is knowing where and how frameworks like Struts are used. ASPM tools can scan the application portfolio to identify instances of Struts, mapping out where it is deployed across the organization. This information is crucial for targeted security measures and efficient patch management. Phoenix Security’s robust Application Security Posture Management (ASPM) system is adept at not just managing, but preempting the exploitation of vulnerabilities through its automated identification system. This system prioritises critical vulnerabilities, ensuring that teams can address the most pressing threats first, optimising resource allocation and remediation efforts.
The Role of Application Security Posture Management (ASPM):
ASPM is vital in managing and securing applications like those built with Apache Struts. It involves continuous assessment, monitoring, and improvement of the security posture of applications. ASPM tools can:
- Identify and Track Struts Components: Locate where Struts is implemented within the application infrastructure.
- Vulnerability Management: Detect known vulnerabilities in Struts and prioritize them for remediation.
- Configuration Monitoring: Ensure Struts configurations adhere to best security practices.
- Compliance: Check if the usage of Struts aligns with relevant cybersecurity regulations and standards.
By leveraging Phoenix Security, you not only unravel the potential threats but also take a significant stride in vulnerability management, ensuring your application security remains up to date and focuses on the key vulnerabilities.
Get in control of your Application Security posture and Vulnerability management
References
- https://github.com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv
- https://github.com/opencontainers/runc/commit/8e1cd2f56d518f8d6292b8bb39f0d0932e4b6c2a
- https://github.com/opencontainers/runc/commit/f2f16213e174fb63e931fe0546bbbad1d9bbed6f
- https://github.com/opencontainers/runc/commit/89c93ddf289437d5c8558b37047c54af6a0edb48
- https://github.com/opencontainers/runc/commit/ee73091a8d28692fa4868bac81aa40a0b05f9780
- https://access.redhat.com/security/cve/cve-2024-21626
- https://github.com/snyk/leaky-vessels-dynamic-detector
- https://snyk.io/blog/cve-2024-21626-runc-process-cwd-container-breakout/
- https://nvd.nist.gov/vuln/detail/CVE-2024-21626
- https://github.com/snyk/leaky-vessels-dynamic-detector
Previous Issues of Vulnerability Weekly
- Apache Active MQ
- Atlassian Critical Vulnerability Exploited by nation-state CVE-2023-22515
- Critical vulnerability F5
- How to update curl and libcurl without panic fixing
- Critical Vulnerabilities in Atlassian Confluence: Zero-Day
- Detect & Mitigate HTTP/2: Rapid Reset Vulnerabilities
- Understanding the libcue Vulnerability CVE-2023
- Understanding and fixing Curl and libcurl
- MOVEit Transfer breach, Zellis compromise CVE-2023-34362
Other Useful resources
Data Visualization of vulnerabilities in the wild
- CISA KEV: https://phoenix.security/what-is-cisa-kev-main/
- Exploit in the wild: https://phoenix.security/what-is-exploitability/
- OWASP/Appsec Vulnerability: https://phoenix.security/what-is-owasp-main/
- CWE/Appsec Vulnerabilities: https://phoenix.security/what-is-cwe-main/
