{"id":113376,"date":"2024-02-03T13:41:10","date_gmt":"2024-02-03T11:41:10","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-runc-pozvolyayushhaya-vybratsya-iz-kontejnerov-docker-i-kubernetes"},"modified":"2024-02-03T13:41:10","modified_gmt":"2024-02-03T11:41:10","slug":"uyazvimost-v-runc-pozvolyayushhaya-vybratsya-iz-kontejnerov-docker-i-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/uyazvimost-v-runc-pozvolyayushhaya-vybratsya-iz-kontejnerov-docker-i-kubernetes","title":{"rendered":"A vulnerability in runc allows escaping from Docker and Kubernetes containers.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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. <\/p>\n

When using Docker or Kubernetes tools, an attack can be executed by preparing a specially crafted container image, after which, upon installation and startup, the container can access the external filesystem. With Docker, it is possible to exploit this through a specially crafted Dockerfile. The vulnerability can also be exploited when running processes in the container with the command 'runc exec' by binding the working directory to the host environment namespace. <\/p>\n

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. <\/p>\n

For instance, an attacker can specify the parameter process.cwd in the container image, pointing to '\/proc\/self\/fd\/7\/', which will bind the working directory to the process pid1 in the container, located in the host environment mount space. Thus, the container image can be configured to execute '\/proc\/self\/fd\/7\/..\/..\/..\/..\/bin\/bash' and, by executing a shell script, overwrite the contents of '\/proc\/self\/exe', which refers to the host\u2019s copy of \/bin\/bash. <\/p>\n

Another variant of the attack allows an attacker, confined within the container, to access the host environment directory if privileged processes are launched in the specified container using the command 'runc exec' with the '--cwd' option. The attacker can substitute the path of the launched process with a symbolic link pointing to '\/proc\/self\/fd\/7\/' and gain access to the filesystem on the host via '\/proc\/$exec_pid\/cwd'. The attacker can also achieve overwriting executable files on the host environment by launching an executable file from the host environment ('\/proc\/self\/fd\/7\/..\/..\/..\/..\/bin\/bash') followed by overwriting the file '\/proc\/$pid\/exe', which points to the running file. <\/p>\n

Additionally, five more vulnerabilities have been identified in Docker toolkit components: <\/p>\n