Container Escape

The fundamental isolation mechanism of Linux containers relies on namespaces (for process, network, and mount isolation) and cgroups (for resource limiting). An escape attack typically exploits a flaw that allows the containerized process to:

• Gain visibility into the host's PID namespace, enabling it to see and signal host processes.
• Escape a mount namespace by accessing the host's filesystem via /proc or improperly mounted sensitive paths like /var/run/docker.sock.
• Break out of cgroup v1 using the release_agent feature, which allows an attacker to execute arbitrary commands on the host when a cgroup is released.

Linux capabilities break down the monolithic root privilege into distinct units. A container escape often occurs when a container is granted dangerous capabilities that are not strictly necessary:

• CAP_SYS_ADMIN: Effectively a backdoor to root; allows mounting filesystems, loading kernel modules, and accessing nsenter.
• CAP_SYS_PTRACE: Allows a process inside the container to trace and inject code into host processes.
• CAP_NET_RAW: Can be abused for ARP spoofing and network-based escape techniques. The principle of Least Privilege Execution mandates dropping all capabilities by default and adding only those explicitly required.

Since all containers share the host's kernel, a single kernel vulnerability can compromise every container on the host. Attackers target:

• Use-after-free bugs in the kernel's network stack or filesystem drivers.
• Dirty Pipe (CVE-2022-0847) and Dirty Cow (CVE-2016-5195) are classic examples where memory corruption allowed overwriting read-only files, enabling privilege escalation to root on the host.
• eBPF vulnerabilities, where a bug in the verifier allows a malicious eBPF program to read/write arbitrary kernel memory. Mitigation requires strict seccomp profiles that block access to vulnerable syscalls and rapid kernel patching.

Mounting the Docker socket (/var/run/docker.sock) inside a container is a common but extremely dangerous pattern for agents that need to manage other containers. This grants the contained process full control over the Docker daemon:

• An attacker can use docker exec to run commands on any other container.
• They can launch a new privileged container with full host filesystem access mounted at /host.
• They can pull a malicious image and run it with --pid=host and --net=host to fully compromise the host. The secure alternative is to use a dedicated orchestrator API with strict Tool Access Control Lists.

The /proc and /sys pseudo-filesystems expose kernel data structures to userspace. Improperly secured, they become powerful escape vectors:

• /proc/sysrq-trigger: Writing to this file can trigger a host reboot or crash.
• /proc/sys/kernel/core_pattern: If writable, an attacker can redirect core dumps to a script, which the kernel will execute with root privileges on the host upon a crash.
• /sys/kernel/uevent_helper: A legacy path that, if writable, allows an attacker to specify a binary that the kernel executes on hotplug events. A hardened seccomp profile should block write access to these paths, and User Namespace Remapping ensures the container's root has no real privileges on the host.

An escape can be premeditated through a compromised container image or runtime:

• A malicious base image from a public registry may contain a hidden reverse shell or a binary that exploits a known kernel vulnerability upon execution.
• A compromised container runtime (e.g., containerd, runc) can be exploited. The CVE-2019-5736 runc vulnerability allowed a malicious container to overwrite the host's runc binary, gaining code execution on every subsequent container start.
• Defense requires verifying image signatures via SLSA provenance, maintaining a strict Software Bill of Materials (SBOM), and using Runtime Security tools like Falco to detect anomalous behavior.