Qualys Security Advisory
Security researchers at Snyk have discovered four vulnerabilities in the core container infrastructure components, tracked as CVE-2024-21626, CVE-2024-23651, CVE-2024-23652, and CVE-2024-23653. The researchers have collect named the vulnerabilities Leaky Vessels. Attackers may exploit these container escape flaws to gain unauthorized access to the underlying host operating system from within the container. An attacker may access sensitive data (credit card numbers, client information, etc.) and launch further attacks once they have access to the underlying host operating system.
These vulnerabilities impact widely used low-level container engine components and container build tools. Therefore, users must check for updates from container build and runtime vendors, including Docker, Kubernetes vendors, cloud container services, and open-source communities. Users should also upgrade systems running container engines and container build tools.
Docker has mentioned in the advisory, “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 (particularly relevant for the CVE-2024-21626 container escape vulnerability).”
CVE-2024-21626: runc process.cwd & leaked fds container breakout
The vulnerability in runc, a tool for spawning and running containers on Linux, originates from specific leaked file descriptors. An attacker can access the host filesystem by tricking a user into running a malicious image, which will allow a container process to access the host filesystem through runc run, or by making a newly-spawned container process (from runc exec) have a working directory in the host filesystem namespace. The attacks can also be modified to completely escape containers by overwriting semi-arbitrary host binaries.
Interestingly, when using higher-level runtimes (such as Docker or Kubernetes), this vulnerability can be exploited by running a malicious container image without additional configuration or passing specific workdir options when starting a container. In the case of Docker, the vulnerability can be exploited from within Dockerfiles.
CVE-2024-23651: Buildkit Mount Cache Race
The vulnerability in the Docker Buildkit arises due to a time-of-check/time-of-use (TOCTOU) race condition when mounting a cache volume at container build time. Buildkit offers cache volumes using the RUN –mount=type=cache directive in a Dockerfile. The directive allows mounting a persistent directory at a controlled location during the Docker image build. This functionality helps improve tooling performance, such as package managers, by keeping the persistent cache between builds.
A source path can be specified inside the recognized cache mount. It was discovered that this source path must be validated to ensure it is not a directory introducing a race condition. The source path can be replaced with a symbolic link between the check and the use (i.e., the source of the mount syscall) by a concurrently running build step that already has the target cache directory mounted. This would result in the mount syscall accidentally mounting an arbitrary directory into the container filesystem.
Successful exploitation of the vulnerability may allow an attacker to access files from the host system to the build container.
CVE-2024-23652: Buildkit Build-time Container Teardown Arbitrary Delete
The vulnerability occurs due to attempts by Buildkit to clean up temporarily added directories after their use. If the target directory for the mount is not present in the container filesystem, it will be created for the mount point and deleted again after use when RUN –mount is used inside a Dockerfile. If the parent of this target directory is replaced with a symbolic link during the container lifetime, the cleanup operations during container teardown will traverse this symbolic link.
An attacker may exploit the vulnerability to erase an arbitrary Dockerfile-defined target file within the host filesystem. Buildkit can delete any file in the host filesystem because it often runs with root rights.
CVE-2024-23653: Buildkit GRPC SecurityMode Privilege Check
The vulnerability originates from a missing privilege check in a GRPC endpoint when called using a custom syntax format. In addition to running containers as build steps, BuildKit also provides APIs for running interactive containers based on built images. In the vulnerable versions, it is possible to use these APIs to ask BuildKit to run a container with elevated privileges. Usually, running such containers is only allowed if there is special security.insecure entitlement is enabled both by buildkitd configuration and authorized by the user initializing the build request.
On successful exploitation, an attacker may escape from the container and achieve complete host root command execution.
- Runc version 1.1.11 and older
- BuildKit version 0.12.4 and older
- Moby (Docker Engine) version 25.0.1, 24.0.8, and older
- Docker Desktop version 4.27.0 and older
- Runc version 1.1.12 or later
- BuildKit version 0.12.5 or later
- Moby (Docker Engine) version 25.0.2, 24.0.9, or later
- Docker Desktop version 4.27.1 or later
For more information, please refer to Docker Security Advisory.
- For CVE-2024-23650, CVE-2024-23651, CVE-2024-23652, and CVE-2024-23653, avoid using the BuildKit frontend from an untrusted source. A frontend image is usually specified as the #syntax line on your Dockerfile or with the –frontend flag when using the buildctl build command.
- To mitigate CVE-2024-24557, make sure to either use BuildKit or disable caching when building images. From the CLI, this can be done via the DOCKER_BUILDKIT=1 environment variable (default for Moby >= v23.0 if the buildx plugin is installed) or the –no-cache flag. If you are using the HTTP API directly or through a client, the same can be done by setting nocache to true or version to 2 for the /build API endpoint.
Qualys customers can scan their devices with QID 379337 to detect vulnerable assets.
Please continue to follow Qualys Threat Protection for more coverage of the latest vulnerabilities.