Researchers have discovered a set of four vulnerabilities in container engine components that they have dubbed “Leaky Vessels,” three of which offer attackers a way to escape containers and perform malicious actions on the underlying host system.
One of the vulnerabilities, designated as CVE-2024-21626, affects 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, a staff security researcher at Snyk (who discovered the flaws and reported them to Docker), says the runC vulnerability allows container escape at both container build and run times.
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 additional attacks.
“Because this vulnerability affects anyone who uses containers to build applications – essentially every cloud-native developer in the world – uncontrolled access could potentially compromise entire Docker or Kubernetes host systems,” warns McNamara.
The defects of “leaky vessels”.
The other three vulnerabilities affect BuildKit, the default toolkit for building container images for Docker. One of them (CVE-2024-23651) implies a race condition related to how cache levels are mounted at runtime. Another (CVE-2024-23653) affects a security model in BuildKit’s remote procedure call protocol; the third vulnerability (CVE-2024-23652) It’s a file deletion flaw, also in BuildKit.
In a Jan. 31 blog post, the organizations recommended by security vendors to “check for updates from all vendors providing their container runtime environments, including Docker, Kubernetes vendors, cloud container services, and open source communities.”
Snyk cited the widespread use of affected container image components and build tools as a reason why organizations should upgrade to fixed versions as soon as their vendors make them available.
Two of the Docker BuildKit vulnerabilities (CVE-2024-23651 and CVE-2024-23653) are compile-time escapes only. “The latest Docker vulnerability (CVE-2024-23652) is an arbitrary host file deletion, which means this is not a classic container escape,” McNamara says.
A growing problem
Container vulnerabilities are a growing problem for enterprise organizations. This was discovered by a study conducted by Sysdig last year 87% of container images in production have at least one high or critical severity vulnerability. The company attributed the high rate of vulnerabilities to organizations’ rush to deploy cloud applications without paying due attention to security issues. A study conducted by Rezilion in 2023 discovered hundreds of Docker container images containing vulnerabilities that standard vulnerability detection and software composition analysis tools cannot detect.
The trend has caused perceptions about container security to change over the past year. A D-Zone survey, for example, found that only 51% of respondents describe containerization as a way to make their applications more secure, compared to 69% in 2021. About 44% said containerization has actually made their application environment less sure, compared to just 7% in 2021.
High entry requirements
McNamara says the four vulnerabilities discovered by Snyk are relatively simple to exploit and typically involve fewer than 30 lines of Dockerfile. However, the entry requirements are high, he says. To exploit flaws, an attacker should 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 aren’t really remotely executable, except in the sense that Kubernetes and similarly affected environments are accessible over the network, 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 is functionally local.”