If exploited, these flaws can allow attackers to gain unauthorized access to sensitive information or generally cause problems
Recently the news of the ddiscovery of new vulnerabilities in runC (a CLI tool for building and running containers on Linux) CVE-2024-21626 and in BuildKit (CVE-2024-23651, CVE-2024-23652 and CVE-2024-23653), being the one of greatest concern CVE-2024-21626, since it is a critical vulnerability that allows access to the file system of the host operating system.
CVE-2024-21626 allows access to the host environment file system from an isolated container. During an attack, an attacker can overwrite some executable files in the host environment and execute their code outside the container.
This is especially concerning in environments like Kubernetes, where containers run on shared nodes. By exploiting this vulnerability, an attacker can gain privileged control over the host, potentially granting unauthorized access to other pods and data of others on the same node.
Furthermore, this vulnerability also affects build processes running in container environments, giving attackers the opportunity to establish a foothold within a build process. This scenario could result in an attacker obtaining elevated credentials, which would grant you access to critical production workloads or other sensitive environments. In essence, the impact extends beyond simply leaking information or executing arbitrary code, and could compromise the integrity and security of the entire development and production environment.
In environments where Docker or Kubernetes are used, an attack can be carried out using a specially crafted container image. Once this image is installed and launched, the attacker can access an external file system from the container. In the case of Docker, it is possible to operate through a specially designed Dockerfile. The vulnerability can also be exploited if processes are started in a container using the "runc exec" command and linking the working directory to the namespace of the host environment.
The main problem is a file descriptor leak and while doing O_CLOEXEC all the file descriptors before executing the container code, the file descriptor is open when doing setcwd(2), which means that the reference can be kept alive in the container by setting the work mode of the directory as a path resolved through the file descriptor (yeThe non-dumpable bit is not set after execve(2), which means there is multiple ways to attack this besides bad configurations).
The cause of the vulnerability lies in the leak of internal file descriptors. Before executing the code inside the container, runc closes all file descriptors using the O_CLOEXEC flag. However, subsequent executions of setcwd() leave open a file descriptor that points to the working directory and remains accessible after the container is started. Several basic scenarios have been proposed to attack the host environment using the remaining file descriptor.
It is mentioned that an example of vulnerability exploitation is if a container was configured:
To set process.cwd to /proc/self/fd/7/, the resulting pid1 process will have a working directory in the host's mount namespace, and therefore the spawned process will be able to access the entire system. host files. This alone is not an exploit against runc. An attacker can also trick a user into running a malicious container image, allowing a container process to reach the host file system via runc. This can extend to overwriting host binaries, resulting in a complete container escape.
Finally, it should be mentioned that The vulnerability has been fixed in runc version 1.1.12, so the recommendation is to update to the new version. If you are interested in learning more about it, you can consult the details In the following link.