The Rust Runtime That Blinked: Breaking Out of Youki via Symlinks

In the modern infrastructure landscape, youki has emerged as the cool, memory-safe cousin to the standard runc container runtime. Written in Rust, it promises to banish the specters of buffer overflows and use-after-free bugs that have plagued C/C++ tools for decades. It adheres to the OCI (Open Container Initiative) spec, meaning it plugs right into Docker and Kubernetes. Everyone loves a rewrite, especially when it comes with the safety guarantees of the borrow checker.

But here is the cynical truth about security: Logic bugs don't care about your memory safety.

CVE-2025-54867 is a stark reminder that even if your language prevents you from shooting your foot off with a pointer, you can still happily logic-bomb your own application. This vulnerability is a classic "Time-of-Check to Time-of-Use" (TOCTOU) adjacent issue—or rather, a "Time-of-Use without Check" issue. It allows a malicious container image to reach out of its sandbox and touch the host filesystem during the container initialization phase, all because the runtime trusted the contents of the container's filesystem a little too much.

To understand this bug, you have to understand how containers boot. When you start a container, the runtime (youki) sets up a namespace (the sandbox) and a root filesystem (rootfs). However, a Linux system isn't functional without certain pseudo-filesystems, specifically /proc and /sys. These aren't real files on a disk; they are interfaces to the kernel.

The runtime's job is to mount these from the host kernel into the container's rootfs. Usually, it looks like this:

1. Runtime prepares rootfs.
2. Runtime mounts proc to rootfs/proc.
3. Runtime mounts sysfs to rootfs/sys.

The flaw in youki (versions < 0.5.5) was breathtakingly simple: It assumed rootfs/proc and rootfs/sys were actual directories.

It performed the mount() syscall blindly. If a malicious attacker provided a container image where /proc was not a directory, but a symbolic link pointing to a location on the host (like /host/target), the Linux kernel—doing exactly what it is told—would follow that link. The result? youki unintentionally mounts the proc filesystem onto the host's filesystem, bypassing the container boundary entirely.

Let's look at the logic failure. In the vulnerable versions of crates/libcontainer/src/rootfs/mount.rs, the code essentially iterated through required mounts and applied them. It lacked a critical sanity check that has become standard in runtimes like runc (which suffered this exact same vulnerability years ago).

The fix introduced in commit 0d9b4f2 adds the necessary paranoia. The developers had to implement a check to ensure the mount destination is a real directory and not a symlink before performing the action.

The Fix Logic:

// Pseudo-code representation of the fix in rootfs/mount.rs
 
let metadata = fs::symlink_metadata(&dest_path)?;
if !metadata.is_dir() {
    // If it's not a directory (e.g., it's a symlink), bail out immediately.
    return Err(Error::from("filesystem proc must be mounted on ordinary directory"));
}
 
// Additionally, for specific /proc sub-mounts, a whitelist was added:
fn check_proc_mount(...) {
    // rigorous checking to ensure we aren't mounting /proc/sys over /etc/shadow
}

This change forces the runtime to validate the topology of the container image before trusting it with a mount operation. It explicitly blocks the symlink vector by failing the container start process if /proc or /sys are detected as links.

Exploiting this is conceptually similar to the Road Runner painting a tunnel on a wall, and the Coyote (youki) running right into it, expecting a real tunnel. Here is how an attacker weaponizes this:

1. The Setup An attacker creates a malicious OCI image (or Docker image). Instead of a standard folder structure, they manipulate the rootfs tarball.

# Inside the malicious image build context
rm -rf proc
ln -s /../../../../home/user/.ssh/ proc

2. The Trigger The attacker submits this image to a system using a vulnerable version of youki. The runtime pulls the image and extracts the rootfs. It sees the proc entry, but currently, it's just a file on disk.

3. The Execution youki begins the initialization. It calculates the mount target: container_root + "/proc". Because of the symlink we planted, this path resolves to /home/user/.ssh/ on the host (depending on how the path resolution handles the breakout).

4. The Payload youki executes the mount. The host's /home/user/.ssh/ is now overlaid with the proc filesystem. While this specific example might just obscure the SSH keys (making them unreadable), clever manipulation of bind mounts or /sys writes can lead to overwriting host configurations or tricking the host kernel into executing commands.

While the CVSS score sits at a 7.0 (High), the real-world implications depends heavily on your architecture. If you are using youki in a multi-tenant Kubernetes cluster, this is a severe issue.

1. Host Filesystem Tampering By redirecting mounts, an attacker can mask critical host files. In some scenarios, if the mount is read-write (which is common for certain bind mounts), they might be able to modify resources on the host.

2. Isolation Breakout The core promise of a container is that the inside cannot affect the outside. This vulnerability fundamentally breaks that promise. It allows the container image—a static asset—to dictate operations on the host OS.

3. Denial of Service At a minimum, an attacker can corrupt the host's mount namespace, potentially causing instability or crashing other services running on the node by overlaying critical directories with pseudo-filesystems.

The mitigation here is binary: you are either vulnerable or you are patched. There are no configuration tweaks that reliably prevent this behavior inside the runtime itself without code changes.

Immediate Action: Upgrade youki to version 0.5.5 or later immediately. The patch includes fs::symlink_metadata checks that render this attack vector inert.

Defense in Depth: If you cannot upgrade immediately, you must rely on input validation upstream. Use container image scanners (like Trivy or Clair) and configure custom policies to reject images where /proc, /sys, or /dev are symbolic links. However, detecting this statically in a tarball can be tricky if the attacker uses obfuscation techniques. The only real fix is a patched runtime.