Vulnerability: Docker runc process.cwd and leaked fds container breakout (CVE-2024–21626)
CVE-2024–21626 is a significant vulnerability found in all versions of runc up to version 1.1.11.
This vulnerability is particularly worrisome as it permits a container escape, granting unauthorized access to the host’s file system. Essentially, an attacker can exploit this vulnerability by running a malicious container or constructing a container using a compromised Dockerfile or base image.
The breach occurs due to the way the WORKDIR directive in the Dockerfile is processed, specifically the sequence of operations when setting the working directory for container processes. By exploiting this weakness, attackers can maintain access to privileged host directory file descriptors, even after they should have been closed, potentially allowing them to gain full control over the host system.
Vulnerability exploitation:
First, run a container of your choice using the command below. In my case, I use the Debian image ‘bookworm’.
-w /proc/self/fd/8
: This option specifies the working directory inside the container. In this case, it’s set to ‘/proc/self/fd/8’. This directory corresponds to file descriptor 8 of the current process, which can be a way to access specific resources within the container.
--name cve-2024-21626
: This option assigns a name to the running container. In this case, the name is set to 'cve-2024-21626'.
--rm
: This option indicates that the container should be automatically removed when it exits. This is useful for temporary containers that you don't want to persist after they have finished their task.
docker run -w /proc/self/fd/8 --name cve-2024-21626 --rm -it debian:bookworm
After running the Docker command, we encounter an error related to the ‘getcwd’ function, which cannot access parent directories. However, if we have already mounted the working directory into ‘/proc/self/fd/8,’ then if we wish to access the system directory, we can execute the ‘ls’ command as follows: ‘ls -la ../../../var/www/html’. This will allow us to view the content of the directory that exists on the host operating system, potentially leading to root escalation.
The previous image contains a list of files that we enumerated using the Docker container. After this analysis, we concluded that we have full control of the host.