Leaky Vessels Vulnerability Sinks Container Security

Researchers have uncovered a hole in the open source runc container engine wide enough for attackers to easily swim through and down to the underlying host operating systems, where they could do all sorts of damage to your systems.

“An attacker could use [this vulnerability] to gain unauthorized access to the underlying host operating system from within the container,” security firm Snyk advised Wednesday in a blog post on this vulnerability and a set of others it has dubbed “Leaky Vessels.”

The maintainers of the runc command line interface first identified the original issue — a leaky file descriptor — and rushed to release an update, runc v1.12, that fixes the core issue (described in ).

Until everyone upgrades, however, users of tools such as Docker, Kubernetes and cloud-based container services should be on the lookout for patches from their vendors, Snyk advised.

Docker, among other tools, uses runc as its default container runtime engine. Docker originally created runc and then bequeathed it to the Open Container Initiative to maintain as a vendor-neutral open source project.

On Wednesday, Docker quickly rushed out patches for runc, along with associated vulnerabilities found in the open source Moby Docker engine and BuildKit.

GitHub ranked the vulnerability with an 8.6, a “high severity level” on the CVSS rating scale, meaning the hole could result in significant downtime and/or data loss, though it is difficult to exploit. Docker pointed out, it could also be used to poison the integrity of the build cache.

Snyk researchers have reported finding no exploits thus far in the world that make use of this bug.

The Damage Leaky Vessels Could Do

With such a vulnerability, an attacker can access and then take control of the underlying operating system. From there they could access other data on the system (such as credentials), and launch further attacks.

“With the widespread adoption of containerization technologies in both development and production environments, such exploits pose significant risks to data integrity, confidentiality, and system stability,” a Red Hat bulletin pointed out Thursday.

A system could be affected by either running an image poisoned with the attack code or by building a container using a malicious Dockerfile or upstream image.

“These vulnerabilities can only be exploited if a user actively engages with malicious content by incorporating it into the build process or running a container from a suspect image,” wrote Docker Senior Security Engineer Gabriela Georgieva in a blog post Wednesday.

“We strongly urge all customers to prioritize security by applying the available updates as soon as they are released. Timely application of these updates is the most effective measure to safeguard your systems against these vulnerabilities and maintain a secure and reliable Docker environment.”

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.

These demos show a container being able to read /etc/shadow via docker run or docker build commands.

They’re pulling specifically crafted images with the exploit preloaded pic.twitter.com/zMRaYufps1

— Matt Johansen (@mattjay) January 31, 2024

BuildKit Is Impacted by Leaky Vessels too

Snyk reported on three more closely related vulnerabilities in the BuildKit, often used in conjunction with runc. All are also ranked with a high severity level:

• : 
• : 
• : 

The runc engine is “one of the more low-level container runtimes, so users generally don’t interact with runc directly, they interact with some other abstraction on top that then uses runc to execute commands,” explained Jimmy Mesta, CTO and co-founder of the Kubernetes security firm KSOC, in a blog post. “runc works with other software, like BuildKit, to accomplish activities like unpacking the image layers and launching container processes, getting the file system in place, and cleaning up these processes and files once the container is deleted. In container runtime, BuildKit would be what builds the image, while runC does the actual execution of each step.”

This is not the first time runc has been plagued with an unintentional escape hatch. In 2019, TNS reported on Runcescape (CVE-2019-5736) discovered by Polish researchers investigating namespace-based sandboxes.