Operator On The Wire
← Back to Knowledge Base
OOTW / Chapter II - Local / 02. Containers / Container Escape / Attacks

Kernel Exploits

Containers share the host kernel.

If the host kernel is vulnerable and the container has enough reachable attack surface, a kernel exploit may break container isolation.

Kernel exploitation is not the first escape path to try. Misconfiguration is more common. Check sockets, mounts, capabilities, and namespaces first.


Preconditions

Kernel escape depends on:

  • Host kernel version
  • Enabled kernel features
  • Container capabilities
  • Seccomp profile
  • AppArmor or SELinux profile
  • User namespace configuration
  • Available syscalls
  • Architecture
  • Exploit reliability

The same CVE may be exploitable in one container and blocked in another.


Enumeration

Check kernel:

uname -a
cat /proc/version

Check restrictions:

cat /proc/self/status | grep Seccomp
cat /proc/self/attr/current 2>/dev/null
capsh --print

Check namespaces:

readlink /proc/self/ns/*
cat /proc/self/uid_map

Examples To Know

Examples historically relevant to container escape research:

CVE-2022-0847 Dirty Pipe
CVE-2022-0185 fs_context heap overflow
CVE-2021-22555 netfilter heap out-of-bounds write
runC container runtime vulnerabilities
overlayfs vulnerabilities

Do not memorize CVE lists as the technique.

The technique is:

container shares host kernel
kernel bug gives elevated kernel capability
kernel-level compromise breaks container boundary

Tooling

Kernel exploit suggestion tools can help identify candidates:

linux-exploit-suggester
linux-smart-enumeration
linpeas
CDK

Use them as triage, not proof.

Example workflow for linux-exploit-suggester in a disposable lab:

wget https://raw.githubusercontent.com/mzet-/linux-exploit-suggester/master/linux-exploit-suggester.sh
chmod +x linux-exploit-suggester.sh
./linux-exploit-suggester.sh

Always verify:

  • Kernel version
  • Distribution patches
  • Required config
  • Required capability
  • Required namespace
  • Required syscall
  • Crash risk

Operational Caution

Kernel exploits can crash hosts.

In training, only run kernel exploits in disposable lab VMs.

In assessments, use non-destructive evidence when possible:

  • Kernel version
  • Missing patches
  • Required capabilities present
  • Seccomp disabled
  • Known vulnerable configuration

Remediation

  • Keep host kernels patched.
  • Keep container runtime patched.
  • Keep seccomp enabled.
  • Keep AppArmor or SELinux enabled.
  • Drop unnecessary capabilities.
  • Avoid privileged containers.
  • Use user namespaces where appropriate.
  • Reduce exposed kernel attack surface.
  • Monitor for suspicious syscall patterns and exploit artifacts.

Containers are only as strong as the kernel boundary underneath them.