cap_sys_ptrace capability abuse

Linux capabilities split root's powers into specific privileges that can be granted to a binary. cap_sys_ptrace enables the ptrace(2), process_vm_readv(2) and process_vm_writev(2) calls: it lets a process attach to another, read and write its memory. It is meant for debuggers (gdb, strace), but if it is granted to an interpreter (for example python2.7), whoever runs it can inject code into any process it can reach, including those running as root.

You spot it with getcap:

getcap -r / 2>/dev/null
# /usr/bin/python2.7 = cap_sys_ptrace+ep

The +ep means effective + permitted: the capability is active when the binary runs. The escalation consists of injecting shellcode into a root process. The usual flow:

1. Pick a victim process running as root that is stable (Apache, a daemon):

ps -faux | grep apache   # note the PID

1. With a Python script that uses ctypes + ptrace, attach to that PID, write shellcode into its memory (for example a bind shell on port 5600) and redirect execution to it.
2. Connect to the port the shellcode opens: the shell inherits the uid=0 of the hijacked process.

python2.7 exploit.py <root_PID>
nc <ip> 5600      # root shell

No password to crack and no kernel memory bug to exploit: the capability is the permission to manipulate another process's memory.

Requirements. A binary with cap_sys_ptrace runnable by our user, a root process to attach to and (barring hardening) no seccomp filter restricting ptrace. Yama (/proc/sys/kernel/yama/ptrace_scope) can limit it, but the capability usually suffices to bypass it.

How to detect it. The unmistakable signature is a ptrace(PTRACE_ATTACH/POKETEXT) or process_vm_writev call from a non-privileged process (a python/perl) against a root process: auditd with -a always,exit -F arch=b64 -S ptrace records it, and a seccomp/eBPF rule can alert. At rest, getcap -r / showing cap_sys_ptrace on an interpreter is already the deviation. The observable consequence is a stable server process (Apache, a daemon) suddenly opening an unexpected listening socket (the bind shell) or spawning /bin/sh for no reason, with its memory altered by another PID.

Defence. Do not grant cap_sys_ptrace to interpreters or general-purpose binaries; reserve it for specific debuggers, isolate with seccomp and raise ptrace_scope. Related to cap_setuid abuse as another dangerous capability.