On March 2023, a significant security issue was revealed in runc, the lightweight universal container runtime used by Docker, Kubernetes, CRI-O, and several other container tools. The vulnerability—CVE-2023-27561—allows privilege escalation due to incorrect access control. This post will break down what happened, why it matters, and how an attacker could exploit it, all in straightforward language. We'll look at the code, link original references, and spell out how defenders can protect themselves.

What is runc?

runc is a command-line tool for spawning and running containers following the Open Container Initiative (OCI) specification. If you run containers, you're almost certainly using runc—it's a building block for Docker, containerd, CRI-O, Podman, and others.

What is CVE-2023-27561?

CVE-2023-27561 affects runc versions up to 1.1.4 (fixed in 1.1.5). This vulnerability can let a malicious user in one container escalate privileges, potentially affecting the host system or other containers.

Root Cause

The issue is tied to incorrect access control in runc's handling of custom volume mounts inside containers. Specifically, the bug lives in the way runc sets up mounted filesystems in libcontainer/rootfs_linux.go.

Even more concerning: it's a regression of CVE-2019-19921—meaning an old bug that had been fixed re-appeared in runc.

What’s the Threat Model?

To exploit this, an attacker must be able to:

Run custom container images (arbitrary code).

This scenario is realistic on multi-user platforms or CI/CD systems where users can launch their own containers with specific mounts.

The Vulnerability Explained

Normally, containers are designed to be isolated from each other and from the host. This isolation includes filesystems—containers should not be able to peek into, modify, or interfere with mounts belonging to other containers, or mount normally restricted files (like /proc or /sys) in unsafe ways.

CVE-2023-27561 bypasses these isolation controls

- When two containers are started close together, runc can mistakenly allow race conditions in setting up volume mounts.
- The attacker crafts a situation where a container ends up with unsafe mount access—such as mounting sensitive host files, or shadowing critical paths—for escalating privileges or escaping the container.

This happens because of incomplete validation logic in rootfs_linux.go relating to symlink resolution, bind mounts, and path traversal.

Proof-of-Concept: Attack Demonstration

Let’s look at a high-level example. (Don’t use this irresponsibly—this is for learning and defense).

Prepare a malicious bind mount:

The attacker creates a host directory, say /tmp/attack, and crafts a symlink inside it that points to a sensitive location, such as /etc.

Launch Container A with a bind mount

- Mounts /tmp/attack/symlink to /containerdata.
3. Simultaneously launch Container B with an overlapping mount or a conflicting mount configuration.

If runc fails to properly check the real destination of the symlink during setup, the attacker can manipulate which host files get mounted in their container, sometimes tricking runc into mounting the real /etc into the container at /containerdata.

Here is a simplified pseudocode highlighting where the bug comes in (libcontainer/rootfs_linux.go)

// Before mounting, runc tries to resolve symlinks (unsafe)
resolvedPath, err := filepath.EvalSymlinks(mountSource)
// But attacker can change mountSource between checks (TOCTOU bug)
// Mount proceeds with outdated checks
mount(resolvedPath, containerDest, ...)

On the host

mkdir /tmp/vuln
ln -s /etc /tmp/vuln/symlink

Start container run (if platform allows)

docker run --rm -v /tmp/vuln/symlink:/hostetc mymaliciousimage
# Inside the container, /hostetc is host's /etc!

If the race is hit (which with scripting is possible), /etc from the host is exposed within the container.

References

- Original runc Advisory
- runc 1.1.5 Release Notes (Patch)
- CVE-2023-27561 NVD Entry
- CVE-2019-19921 Regression
- See the affected code section: libcontainer/rootfs_linux.go

Upgrade runc Immediately:

- If you use Docker, Kubernetes, CRI-O, Podman, or anything running containers, make sure your runtime is using runc 1.1.5 or later.

Why Does This Matter?

Modern infrastructure is built on containers. A single privilege escalation bug in runtimes like runc can let an attacker take over entire clusters. The fact that this was a regression of an old bug shows how subtle and hard-to-fix container isolation can be.

If you run any container-based service, patch now.

Summary

- CVE-2023-27561: Incorrect Access Control in runc, allows privilege escalation via custom volume mounts.

Stay secure!

_Exclusive Content by AI, for defenders and devs. Please share with your ops and security teams. For deep technical analysis, see the runc advisory and release notes._

Timeline

Published on: 03/03/2023 19:15:00 UTC
Last modified on: 04/21/2023 04:15:00 UTC