|Container||Node||Escape to Host, T1611|
Given the requisite capabilities, abuse the legitimate OS debugging mechanisms to escape the container via attaching to a node process.
SYS_PTRACE capability, which allows the use of
ptrace(). This system call allows a process to monitor and control the execution of another process.
To perform this attack, the container must be started with the option
hostPID: true, which enables the sharing of the PID address space between the container and the host operating system, allowing the container process to see every other process running on the host. And the container needs to be granted
See the example pod spec.
From within a running container, determine whether it is running with the required capabilities:
# Check the current process' capabilities cat /proc/self/status | grep CapEff # CapEff: 00000000a80425fb # Decode the capabilities (on current box or offline) and check for CAP_SYS_PTRACE and CAP_SYS_ADMIN # NOTE: can install capsh via apt-get update && apt-get install libcap2-bin capsh --decode=00000000a80425fb | grep cap_sys_admin capsh --decode=00000000a80425fb | grep cap_sys_ptrace
Install a debugger into the container:
Attach to the process and inject a shell command:
- Monitor for GDB (or other debugging tools) installation.
- Detect invocation of ptrace() from within a container.
Implement security policies
Use a pod security policy or admission controller to prevent or limit the creation of pods with additional powerful capabilities.
Avoid running containers as the
root user. Enforce running as an unprivileged user account using the
runAsNonRoot setting inside
securityContext (or explicitly setting
runAsUser to an unprivileged user). Additionally, ensure that
allowPrivilegeEscalation: false is set in
securityContext to prevent a container running as an unprivileged user from being able to escalate to running as the