The Container Escape Room: An Exploration of Container Escapes

### Overview In this talk, Amit, a security researcher at ARMO (the makers of Kubescape), explores the mechanics of container escapes, common attack vectors, and effective defense strategies. Containers are fundamentally isolated Linux processes that share the underlying host kernel rather than full virtual machines. Because containers rely on kernel configurations rather than hypervisor hardware isolation, misconfigurations, kernel vulnerabilities, or runtime flaws can break isolation boundaries and permit container escapes.

### Key Topics - **Container Anatomy & Building Blocks**: Containers rely on core Linux kernel primitives: namespaces (defining visibility, such as PID, mount, and user namespaces), seccomp (system call filtering via restrict mode or BPF filters), Linux Security Modules (LSMs such as AppArmor and SELinux for access control checks), Linux capabilities (splitting root privileges, such as CAP_BPF), and cgroups (resource limits for CPU and memory). - **Container Runtimes**: Low-level container runtimes such as runc, crun, or youki follow the OCI specification to create, start, and manage processes using a root filesystem and a configuration bundle. Higher-level tools like Docker and containerd wrap these runtimes. - **Primary Escape Vectors**: Container escapes typically stem from three main categories: kernel vulnerabilities, container misconfigurations (the most common vector), and vulnerabilities within the container runtimes themselves.

### Technical Details - **Kernel Exploits (Dirty Pipe - CVE-2022-0847)**: Discovered by Max Kellerman, Dirty Pipe allows overwriting read-only files in the page cache via an uninitialized `PIPE_BUF_FLAG_CAN_MERGE` flag in pipe buffers interacting with the `splice` system call. In a container escape scenario, an attacker in an unprivileged container can monitor `/proc` for runc execution (e.g., triggered by `kubectl exec`), exploit Dirty Pipe to overwrite the host runc binary cached in memory, and hijack execution on the host as root. - **Container Misconfigurations**: Common pitfalls include running containers with the `--privileged` flag combined with `hostPID` (enabling tools like `nsenter` to spawn a shell in the host's root namespace), mounting sensitive host paths or runtime sockets (e.g., exposing Docker sockets to run Docker-inside-Docker), and assigning dangerous capabilities. Amit demonstrates how granting `CAP_BPF` allows an attacker inside a container to use the `bpf` syscall to alter global kernel BPF maps utilized by security agents like Tetragon (Cilium), selectively deleting process tracking entries and evading detection. - **Data from Kubescape Scans**: Analysis of over 10,000 clusters revealed that 37% of clusters had credentials inside configuration files, 23% ran containers with dangerous capabilities, and privileged containers ranked among the top five misconfigurations. - **Runtime Vulnerabilities (Leaky Vessels - CVE-2024-21626)**: Discovered by Snyk, this runc vulnerability involved an internal file descriptor leak (cgroup fd) to the container. Attackers can exploit this by setting `WORKDIR` to `/proc/self/fd/7` in a malicious Dockerfile, granting file access back to the host filesystem. - **MicroVMs**: Technologies like AWS Firecracker and Kata Containers address shared-kernel risks by creating lightweight virtual machines with separate kernels under the OCI specification, though historical research shows nested isolation boundaries can still occasionally have escapes.

### Takeaways - **Patching**: Rapidly patching host kernels mitigates severe zero-day exploitation like Dirty Pipe. - **Address Misconfigurations**: Misconfigurations account for the majority of practical escapes; use continuous scanning and admission policies (such as CEL policies in Kubernetes 1.30 or Kyverno) to block privileged pods and dangerous capabilities. - **Least Privilege & Isolation**: Avoid granting root within containers, enforce Kubernetes Network Policies to limit lateral movement, and use seccomp profiles to restrict system calls (e.g., blocking `splice` prevents Dirty Pipe exploitation even on vulnerable kernels).