● CVE-2024-21626 / Leaky Vessels Landmark

CVE-2024-21626: runc 'Leaky Vessels' Container Breakout Teardown

How an internal /proc/self/cwd file descriptor leak in libcontainer/init_linux.go allowed container processes to break out to the host filesystem across Docker and Kubernetes.

💡 Простое объяснение на пальцах (ELI5)

Imagine you are sent to a prison cell. The guard walks in, closes the heavy steel door, but forgets his master keychain hanging on the inside keyhole! You simply turn the key, walk through the door, and now you have the keys to every single cell and door in the entire prison fortress.

Ключевые концепции и архитектурные термины

runc: The universal low-level container runtime used by Docker, containerd, and Kubernetes to spawn and run OCI containers.
File Descriptor Leak: Failing to mark an open file handle with `O_CLOEXEC`, leaving it accessible to child processes after `execve()`.
/proc/self/cwd: A Linux virtual file path representing the current working directory of the process.
Container Breakout: Escaping the isolated container namespace to access and overwrite files on the underlying host operating system.

Пошаговая механика выполнения атаки

Step 1

1. Malicious Docker Image

The attacker crafts a container image setting WORKDIR /proc/self/fd/7.

Step 2

2. Container Execution

When runc initializes the container, internal file descriptor 7 still points to host /sys/fs/cgroup.

Step 3

3. Directory Traversal via Procfs

The container's entrypoint process uses ../../../../ relative traversal through the leaked handle.

Step 4

4. Host Filesystem Compromise

The container process lands directly in the host root directory (`/`), overwriting host cron jobs and binaries.

Исходный код: Уязвимость vs. Исправленный патч

Представлено на понятном высокоуровневом исходном коде (без ассемблера и бинарных дампов).

УЯЗВИМЫЙ КОД ДО ПАТЧА

// VULNERABLE: libcontainer/init_linux.go before patch
func (l *linuxStandardInit) Init() error {
    // ROOT CAUSE:
    // runc opened /sys/fs/cgroup and internal procfs directories during setup,
    // but did not close them before invoking execve() into the user container!
    // File descriptors remained open and accessible inside the container!
    return syscall.Exec(l.config.Args[0], l.config.Args, os.Environ())
}

БЕЗОПАСНОЕ ИСПРАВЛЕНИЕ

// SECURE: libcontainer/init_linux.go patch
func (l *linuxStandardInit) Init() error {
    // 1. Unconditionally verify and close ALL internal file descriptors before exec
    if err := finalizeNamespace(l.config); err != nil {
        return err
    }
    
    // 2. Explicitly close any leaked descriptor indices (> 2)
    closeExecFds(l.config.PassedFiles)
    
    // 3. Verify current working directory is strictly inside container rootfs
    if err := verifyCwdInsideRootfs(l.config.Rootfs); err != nil {
        return fmt.Errorf("working directory escaped container rootfs: %w", err)
    }

    return syscall.Exec(l.config.Args[0], l.config.Args, os.Environ())
}

Инженерный чек-лист для код-ревью и защиты систем

Set `O_CLOEXEC` on all internal file handles opened during container initialization.
Verify that container working directories (`WORKDIR`) resolve strictly inside the container rootfs.
Update `runc`, `containerd`, and `docker` to versions patched against the Leaky Vessels advisory.
Use Linux user namespaces to ensure root inside a container maps to an unprivileged UID on the host.

← Полный каталог уязвимостей Все бюллетени безопасности →