A vulnerability identified as CVE-2024-21626 has been found in the toolset for launching isolated containers runc, used in Docker and Kubernetes. This vulnerability allows access to the host environment's file system from an isolated container. During an attack, an attacker may overwrite certain executable files in the host environment and thereby execute their code outside the container. The issue does not manifest in the runtime crun and youki, which utilize runc, as well as in LXC. The vulnerability has been fixed in runc version 1.1.12.
When using the Docker or Kubernetes toolsets, an attack can be carried out by preparing a specially crafted container image, after which access to the external file system can be achieved from the container. In Docker, there is a potential for exploitation through a specially formatted Dockerfile. The vulnerability can also be exploited when launching processes in the container using the ‘runc exec’ command by binding the working directory to the host namespace.
The vulnerability is caused by a leak of internal file descriptors. Before executing code inside the container, runc closes all file descriptors using the O_CLOEXEC flag. However, after subsequently calling the setcwd() function, a file descriptor remains open that points to the working directory and continues to be accessible after the container is launched. Several basic attack scenarios on the host environment have been proposed using the remaining file descriptor.
For example, an attacker can specify the process.cwd parameter in the container image pointing to ‘/proc/self/fd/7/’, which will bind the working directory in the container to the process pid1 within the host's mounting namespace. Thus, in the container image, it is possible to configure the execution of ‘/proc/self/fd/7/../../../bin/bash’ and overwrite the contents of ‘/proc/self/exe’ through the execution of a shell script, which references the host copy of /bin/bash.
Another type of attack allows an attacker, confined within a container, to access the host environment's directory if privileged processes are launched in the specified container using the command 'runc exec' with the '—cwd' option. The attacker can substitute the execution path of the launched process with a symbolic link pointing to '/proc/self/fd/7/' and achieve opening '/proc/$exec_pid/cwd' for access to the host's file system. The attacker can also enable the rewriting of executable files on the host environment side by organizing the execution of a file from the host environment ('/proc/self/fd/7/../../../../bin/bash') followed by rewriting the file '/proc/$pid/exe', which points to the launched file.
Additionally, five more vulnerabilities have been identified in Docker toolkit components:
- CVE-2024-23651 — a race condition in the BuildKit package used in Docker to transform source code into build artifacts. The vulnerability is caused by using a common mount point with cache ('—mount=type=cache,source=') in concurrently executing build stages, which allows access to files in the host environment from the build container when processing a specially crafted Dockerfile. The vulnerability has been fixed in BuildKit 0.12.5.
- CVE-2024-23652 — an error in removing empty files created for the mount point when using the '—mount' option allows for the deletion of a file outside the container when processing a specially crafted Dockerfile. The vulnerability has been fixed in BuildKit 0.12.5.
- CVE-2024-23653 — an API implementation error in BuildKit allows running a container with elevated privileges despite the state of the security.insecure setting. The vulnerability has been fixed in BuildKit 0.12.5.
- CVE-2024-23650 — a malicious client or front-end BuildKit can cause a crash of the background BuildKit process. The vulnerability has been fixed in BuildKit 0.12.5.
- CVE-2024-24557 — a cache poisoning vulnerability in Moby, a component for building specialized container isolation systems. When processing a specially crafted container image, it's possible to cache data that can be used in subsequent build stages. The vulnerability has been fixed in Moby 25.0.2 and 24.0.9.
Source: opennet.ru
