A vulnerability CVE-2024-21626 was found in the runc isolated container startup toolkit used in Docker and Kubernetes, which allows access to the file system of the host environment from an isolated container. In the course of an attack, an attacker can overwrite some executable files in the host environment and thus achieve execution of their code outside the container. In runtime LXC, crun, and youki, which also use runc, the problem does not appear. The vulnerability is fixed in the runc 1.1.12 release.
In the case of using Docker or Kubernetes tools, an attack can be performed by preparing a specially designed container image, after installing and running it, the container still has the ability to access an external FS. When using Docker, it is possible to use it through a specially designed Dockerfile. The vulnerability can also be exploited when starting a new container instance with the "runc exec" command by binding the working directory to the host environment namespace by specifying a special value in the "workdir" parameter.
The vulnerability is caused by a leak of internal file descriptors. Before running code from the container in runc, all file descriptors are closed using the O_CLOEXEC flag. However, after the subsequent execution of the setcwd() function, a file descriptor was opened, pointing to the working directory and continuing to be available after the container was started. Several basic scenarios of attacking the host environment using the remaining file descriptor are proposed.
For example, an attacker can specify the process.cwd parameter in the container image, pointing to " /proc/self/fd/7/", which will bind to the pid1 process in the container of the working directory located in the mount space of the host environment. In this way, you can configure the container image to run "/proc/self/fd/7 / ../../../bin/bash "and use a shell script to overwrite the contents of "/proc/self/exe", which refers to the host copy of /bin/bash.
Another attack option allows an attacker restricted inside a container to gain access to the host environment directory if privileged processes are running in the specified container using the runc exec command with the--cwd option. An attacker can replace the path of the running process with a symbolic link pointing to "/proc/self/fd/7/ "and open" /proc / $exec_pid/cwd " to access the FS on the host side. An attacker can also achieve overwriting of executable files on the side of the host environment, by organizing the launch of the executable file from the host environment, followed by overwriting the "/proc/$pid/exe" file referring to that launched file.
In addition, five other vulnerabilities were identified in the components of the Docker toolkit::
• CVE-2024-23651 - race condition in the BuildKit package used in Docker to convert source code to build artifacts. The vulnerability is caused by the use of a single shared cache mount point ("--mount=type=cache,source=") in parallel build stages, which allows you to access files in the host environment from the build container when processing a specially designed Dockerfile in BuildKit. The vulnerability was fixed in BuildKit 0.12.5.
• CVE-2024-23652 - error when deleting empty files created for the mount point when using the "--mount " option allows you to delete a file outside the container when processing a specially designed Dockerfile. The vulnerability was fixed in BuildKit 0.12.5.
• CVE-2024-23653 - an error in the API implementation in BuildKit allows you to execute the container with elevated privileges, regardless of the state of the security.insecure configuration. The vulnerability was fixed in BuildKit 0.12.5.
• CVE-2024-23650 - A malicious BuildKit client or frontend can cause a BuildKit background process to crash. The vulnerability was fixed in BuildKit 0.12.5.
• CVE-2024-24557 - possibility of cache poisoning in Moby, a component for building specialized container isolation systems. When processing a specially designed container image, you can ensure that data is stored in the cache, which can be used in the next stages of the build. The vulnerability is fixed in Moby 25.0.2 and 24.0.9.
In the case of using Docker or Kubernetes tools, an attack can be performed by preparing a specially designed container image, after installing and running it, the container still has the ability to access an external FS. When using Docker, it is possible to use it through a specially designed Dockerfile. The vulnerability can also be exploited when starting a new container instance with the "runc exec" command by binding the working directory to the host environment namespace by specifying a special value in the "workdir" parameter.
The vulnerability is caused by a leak of internal file descriptors. Before running code from the container in runc, all file descriptors are closed using the O_CLOEXEC flag. However, after the subsequent execution of the setcwd() function, a file descriptor was opened, pointing to the working directory and continuing to be available after the container was started. Several basic scenarios of attacking the host environment using the remaining file descriptor are proposed.
For example, an attacker can specify the process.cwd parameter in the container image, pointing to " /proc/self/fd/7/", which will bind to the pid1 process in the container of the working directory located in the mount space of the host environment. In this way, you can configure the container image to run "/proc/self/fd/7 / ../../../bin/bash "and use a shell script to overwrite the contents of "/proc/self/exe", which refers to the host copy of /bin/bash.
Another attack option allows an attacker restricted inside a container to gain access to the host environment directory if privileged processes are running in the specified container using the runc exec command with the--cwd option. An attacker can replace the path of the running process with a symbolic link pointing to "/proc/self/fd/7/ "and open" /proc / $exec_pid/cwd " to access the FS on the host side. An attacker can also achieve overwriting of executable files on the side of the host environment, by organizing the launch of the executable file from the host environment, followed by overwriting the "/proc/$pid/exe" file referring to that launched file.
In addition, five other vulnerabilities were identified in the components of the Docker toolkit::
• CVE-2024-23651 - race condition in the BuildKit package used in Docker to convert source code to build artifacts. The vulnerability is caused by the use of a single shared cache mount point ("--mount=type=cache,source=") in parallel build stages, which allows you to access files in the host environment from the build container when processing a specially designed Dockerfile in BuildKit. The vulnerability was fixed in BuildKit 0.12.5.
• CVE-2024-23652 - error when deleting empty files created for the mount point when using the "--mount " option allows you to delete a file outside the container when processing a specially designed Dockerfile. The vulnerability was fixed in BuildKit 0.12.5.
• CVE-2024-23653 - an error in the API implementation in BuildKit allows you to execute the container with elevated privileges, regardless of the state of the security.insecure configuration. The vulnerability was fixed in BuildKit 0.12.5.
• CVE-2024-23650 - A malicious BuildKit client or frontend can cause a BuildKit background process to crash. The vulnerability was fixed in BuildKit 0.12.5.
• CVE-2024-24557 - possibility of cache poisoning in Moby, a component for building specialized container isolation systems. When processing a specially designed container image, you can ensure that data is stored in the cache, which can be used in the next stages of the build. The vulnerability is fixed in Moby 25.0.2 and 24.0.9.
