‘Leaky Vessels’ Cloud Bugs Allow Container Escapes Globally – Source: www.darkreading.com

Source: Jack Sullivan via Alamy Stock Photo

Researchers have uncovered a set of four vulnerabilities in container engine components that they dubbed “Leaky Vessels,” three of which give attackers a way to break out of containers and execute malicious actions on the underlying host system.

One of the vulnerabilities, designated as CVE-2024-21626, impacts runC, the lightweight container runtime for Docker and other container environments. It is the most urgent of the four vulnerabilities, with a severity score of 8.6 out of a possible 10 on the CVSS scale.

Rory McNamara, staff security researcher at Snyk (which discovered the flaws and reported them to Docker), says the runC vulnerability enables container escape at both build-time and run-time of the container.

In worst-case scenarios, an attacker who gains unauthorized access to an underlying host operating system can potentially access anything else running on the same host, including, but not limited to, key credentials that allow the adversary to launch further attacks.

“Since this vulnerability affects anybody using containers to build applications — essentially every cloud-native developer worldwide — unchecked access could potentially compromise entire Docker or Kubernetes host systems,” McNamara warns.

The “Leaky Vessels” Flaws

The other three vulnerabilities affect BuildKit, the default container image building toolkit for Docker. One of them (CVE-2024-23651) involves a race condition related to how cache layers are mounted during runtime. Another (CVE-2024-23653) affects a security model in BuildKit’s remote procedure call protocol; the third vulnerability (CVE-2024-23652) is a file delete flaw, also in BuildKit.

In a blog post on Jan. 31, the security vendor advised organizations to “check for updates from any vendors providing their container runtime environments, including Docker, Kubernetes vendors, cloud container services, and open source communities.”

Snyk cited the wide use of the affected container image components and build tools as a reason why organizations should upgrade to fixed versions as soon as their providers make them available.

Two of the Docker BuildKit vulns (CVE-2024-23651 and CVE-2024-23653) are build-time only escapes. “The final Docker vulnerability (CVE-2024-23652) is an arbitrary host file delete, meaning that it’s not a classic container escape,” McNamara says.

A Growing Problem

Container vulnerabilities present a growing problem for enterprise organizations. A study that Sysdig conducted last year found that 87% of container images in production have at least one high or critical severity vulnerability in them. The company attributed the high percentage of vulnerabilities to the rush by organizations to deploy cloud applications without paying appropriate attention to security issues. Research by Rezilion in 2023 uncovered hundreds of Docker container images containing vulnerabilities that standard vulnerability detection and software composition analysis tools could not detect.

The trend has caused perceptions around container security to change over the last year. A survey by D-Zone, for example, found only 51% of respondents describing containerization as making their applications more secure, compared with 69% in 2021. Some 44% said containerization had actually made their application environment less secure, compared with just 7% in 2021.

High Access Requirements

McNamara says the four vulnerabilities that Snyk discovered are relatively simple to exploit and typically involve less than a 30-line Dockerfile. However, there is a high access requirement, he says. To exploit the flaws, an attacker would need to be able to do the following: run an arbitrary container on the target; build an arbitrary container on the target; or compromise an upstream container or cause a victim system to use a controlled upstream container.

The flaws are not really remotely executable except in the sense that Kubernetes and similarly affected environments are network accessible, McNamara says. “But in the sense of a true ‘remote’ exploit, no,” he says. “There is still a requirement for sufficient access to the environment that it is functionally local.”