Leaky Vessels: a file descriptor left open, and a container that is no longer contained

What it actually is

While setting up a container, runc left an internal file descriptor open across the boundary. A process inside the container that sets its working directory through that descriptor is then operating in the host filesystem rather than the container's.

What an attacker gets: Escape from the container to the host, with whatever privilege the container runtime holds. That is usually root.

When it applies to you, and when it does not

An old package version and a real exposure are different things. These are the conditions this one needs.

• It needs a hostile image or a hostile Dockerfile, because the trigger is a working directory chosen at build or run time.
• Anything running containers on the affected runc is in scope: Docker, Podman, Kubernetes and containerd all use it.
• Restarting the containers is not enough. The daemon that uses runc needs restarting, and long-lived containers started under the old runtime should be recreated.

Check your own server

runc --version 2>/dev/null; docker version --format '{{.Server.Version}}' 2>/dev/null; command -v podman >/dev/null && podman version --format '{{.Server.Version}}'

Whether a container runtime is on this machine at all, and its version. Many servers have runc installed as a dependency without running containers.

Fixed package version, per distribution

From each distribution’s own advisory data, asked per release. A version here is the package version that carries the fix on that release, not the upstream release number.

What SecAI has recorded about it

runc is a CLI tool for spawning and running containers on Linux according to the OCI specification. In runc 1.1.11 and earlier, due to an internal file descriptor leak, an attacker could cause a newly-spawned container process (from runc exec) to have a working directory in the host filesystem namespace, allowing for a container escape by giving access to the host filesystem ("attack 2"). The same attack could be used by a malicious image to allow a container process to gain access to the host filesystem through runc run ("attack 1"). Variants of attacks 1 and 2 could be also be used to overwrite semi-arbitrary host binaries, allowing for complete container escapes ("attack 3a" and "attack 3b"). runc 1.1.12 includes patches for this issue.

Recorded from nvd. Its weakness class is CWE-403 and CWE-668 and CWE-200, from NVD.

• http://packetstormsecurity.com/files/176993/runc-1.1.11-File-Descriptor-Leak-Privilege-Escalation.html
• http://www.openwall.com/lists/oss-security/2024/02/01/1
• http://www.openwall.com/lists/oss-security/2024/02/02/3
• https://github.com/opencontainers/runc/commit/02120488a4c0fc487d1ed2867e901eeed7ce8ecf
• https://github.com/opencontainers/runc/releases/tag/v1.1.12
• https://github.com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv

Read next

Other CVEs explained in full