Skip to main content

Time is of the Essence to Mitigate Vulnerabilities like Leaky Vessels

By February 6, 2024Blog
Mitigate Vulnerabilities Leaky Vessels

By Randall Degges, Snyk, Dana Wang, OpenSSF, and David A. Wheeler, OpenSSF

Time is of the essence to mitigate vulnerabilities like the recent Leaky Vessels in order to reduce the chance of the vulnerabilities being exploited by attackers. As noted in Leaky Vessels: Docker and runc container breakout vulnerabilities, “Snyk security researcher Rory McNamara, with the Snyk Security Labs team, identified four vulnerabilities — dubbed “Leaky Vessels” — in core container infrastructure components that allow container escapes. An attacker could use these container escapes to gain unauthorized access to the underlying host operating system from within the container. Once an attacker gains access to the underlying host operating system, they could potentially access whatever data was on the system, including sensitive data (credentials, customer info, etc.), and launch further attacks.”

What are the Leaky Vessels Vulnerabilities?

The primary vulnerability found is formally identified as CVE-2024-21626, and involves the program “runc” before version 1.1.12 (released 2024-01-31). It’s important to note that the attack can occur by either directly running a malicious image or by building a container image using a malicious Dockerfile or upstream image (i.e., when using FROM). Again, simply building software could lead to a successful attack. A technical analysis provides more detail.

In the process of analyzing this primary vulnerability, 3 other “container escape” vulnerabilities were found, for a total of 4 vulnerabilities. We recommend that you upgrade runc, Docker, and follow relevant vendor advisories immediately to prevent the abuse of these vulnerabilities.

Snyk, an OpenSSF member, also released two open-source tools that can detect the abuse of this vulnerability from within your infrastructure: a static analysis tool and a dynamic tool (that uses eBPF). Synk recommends using the dynamic tool where applicable as it will have fewer false positives due to improved observability. Still, either tool can help you detect bad actors trying to exploit the Leaky Vessels vulnerabilities.

How the OpenSSF Helps Manage Vulnerabilities

OpenSSF’s mission is to make open source software more secure. The communities of OpenSSF have been actively working on technical initiatives that can help address vulnerabilities like leaky vessels:

  1. Secure Software Development Fundamentals Courses. Many developers don’t know how to develop secure software. This should be unsurprising, as most universities don’t require budding developers to learn how to develop secure software, and many developers don’t go to universities to learn their craft. We strongly encourage that all software developers learn how to develop secure software. The OpenSSF even offers free Secure Software Development Fundamentals Courses. Vulnerability CVE-2024-21626 happened because privileges weren’t removed early enough, leading to security checks that were bypassable. The OpenSSF fundamentals courses discuss the importance of providing least privilege and ensuring security checks are non-bypassable.
  2. Coordinated Vulnerability Disclosure (CVD). Coordinated vulnerability disclosure is critical in mitigating globally impactful vulnerabilities before they are known publicly. It reduces the window of opportunities for attackers to exploit the vulnerabilities. The process calls for close collaboration between stakeholders in addressing and mitigating open source vulnerabilities in a timely manner. OpenSSF has published  Guidance for Security Researchers to Coordinate Vulnerability Disclosures with Open Source Software Projects. For OSS projects, OpenSSF has published a Guide to Implementing a Coordinated Vulnerability Disclosure Process for Open Source Projects (e.g., create a file to tell researchers how to report vulnerabilities).
  3. Software Bill of Materials (SBOMs). SBOMs are valuable for systematically and quickly identifying the technology assets that are impacted by the leaky vessel vulnerabilities. They enable organizations to more efficiently assess the risks and impacts of vulnerabilities to their business and customers in order to plan and prioritize the remediation accordingly and remain compliant with regulations. SBOMs allow organizations to coordinate risk assessment and patching efforts with third party software vendors, IaaS and PaaS providers more effectively. Time is of the essence to mitigate the vulnerabilities like Leaky Vessels in order to reduce the chance of the vulnerabilities being exploited by attackers. Establishing a robust technology asset inventory makes effective use of SBOMs. See the recent blog on OpenSSF’s effort in SBOM delivery to help secure open source software.     
  4. Tabletop exercise (TTX). Organizations with mission-critical applications, services or products should execute Tabletop exercises (TTX) regularly in order to improve an organization’s overall security posture. A well-organized TTX simulates a security incident response process by planning a security scenario and bringing all the stakeholders together to respond to it. OpenSSF is planning to publish a template for maintainers, contributors, and open source consumers to enhance incident response capabilities.

If you’d like to connect with others on managing vulnerabilities and other ways to secure open source software, plan to join us at our next event. OpenSSF is the host of Secure Open Source Software (SOSS) Community Days. These community days bring together experts, enthusiasts, and thought leaders, and are filled with engaging discussions and insights into the challenges, innovations, and collaborative efforts shaping the security landscape of open source software. The next SOSS Community Day is April 15, 2024 in Seattle, Washington co-located with Open Source Summit North America. The deadline to submit speaking proposals is February 9, 2024.

About the Authors

RandallDeggesRandall Degges runs Developer Relations & Community at Snyk, where he works on security research, development, and education. In his spare time, Randall writes articles and gives talks advocating for security best practices. Randall also builds and contributes to various open-source security tools. Randall’s realms of expertise include Python, JavaScript, and Go development, web security, cryptography, and infrastructure security. Randall has been writing software for over 20 years and has built a number of popular API services and open-source tools.

DanaDana Wang makes the open source ecosystem more secure. She was formerly responsible for building and operating public cloud edge network security controls at JPMorgan Chase. She also spent time on solutions architecture, building security guardrails, security incident response automation and orchestration, and payment products development. Before joining JPMorgan Chase, she focused on Single Sign On integrations and various portals development at Cigna. Open source software has made every solution possible, and she has developed more appreciation for it.

David A WheelerDr. David A. Wheeler is an expert on developing secure software and on open source software (OSS) development. He wrote the book “Secure Programming HOWTO” on how to develop secure software, and his work on countering malicious tools (“Fully Countering Trusting Trust through Diverse Double-Compiling (DDC)”) is widely cited. He is the Director of Open Source Supply Chain Security at the Linux Foundation, and teaches graduate courses in developing secure software at George Mason University (GMU). He is also the lead for the Linux Foundation’s OpenSSF Best Practices badge project. Dr. Wheeler has a PhD in Information Technology, a Master’s in Computer Science, a certificate in Information Security, and a B.S. in Electronics Engineering, all from George Mason University (GMU). He is also a Certified Information Systems Security Professional (CISSP) and a Senior Member of the Institute of Electrical and Electronics Engineers (IEEE).

This post represents the views of the authors & does not necessarily reflect those of all OpenSSF members.