Why the leaked file descriptor pointing to cgroup described in CVE-2024-21626 can not be seen via /proc/xxx/fd either inside the container or on the host

[jiuchen1986]

As the title speaking, I understood the issue is due to a remaining opened file descriptor by runc that is inherited by the container process. My question is why this fd can not been seen via either /proc/self/fd inside container or /proc/pid_of_container_process/fd on the host. Please somebody help me understand this. Thanks!

BTW, my worker system is

~# cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.3 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.3 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy

and runc version is

~# runc --version
runc version 1.1.9
commit: v1.1.9-0-gccaecfcb
spec: 1.0.2-dev
go: go1.20.3
libseccomp: 2.5.4

[lifubang]

Because we use ‘exece’ to start the container init process, before execve, runc has marked all unnecessary opened fds as ‘close-on-exec’. We can only see it before execve. Please see:
https://github.com/opencontainers/runc/blob/main/libcontainer/init_linux.go#L307-L313

[jiuchen1986]

Thanks! That explains!

[cyphar]

The file descriptor was not leaked to the container, it was an internal file descriptor leak to runc init (which is the process that eventually does an exec to become the container process).

While some other folks described the issue as a simple "file descriptor leak", this is not entirely accurate. We have had code to ensure that we do not leak extra file descriptors to the container before said exec since 2014.

The oversight was that it was possible to maliciously configure the container so that runc init uses that file descriptor to escape before it is closed before exec. (We have had to add new bits of hardening to this over time -- we found a kernel bug with O_CLOEXEC and the dumpable flag when fixing CVE-2016-9962 which required some additional hardening, and now with CVE-2024-21626 we've added even more hardening to reduce possible internal fd leaks and leaks that execve(2) could exploit).

[jiuchen1986]

Got it. Thanks for the detailed explanations!