Off to the PTraces

Yesterday, a privilege escalation bug in the ptrace syscall was made public by Jann Horn at Project Zero, deemed CVE-2019-13272. The culprit was broken permission and object lifetime handling by the PTRACE_TRACEME request, which basically let Linux processes ask an attacker to “trace me like one of your French girls.”

Why it’s cool: This vuln affected any Linux distros using a 4.x or 5.x kernel (i.e. a lot of distros), giving it an impressive footprint. Exploiting the bug is conceptually interesting due to the borked permissions that PTRACE_TRACEME allows. The object lifetime handling issue potentially allows for memory corruption, but it requires code racing in a precise way (there is a public, reliable PoC, but I’m only going to cover the permissions issue here).

It turns out with PTRACE_TRACEME, the kernel recorded the tracer’s credentials in addition to those of the parent process. The scenario the researcher outlined involves a parent process that forks a child, which forks a child. The first child uses a command like pkexec (used to run programs as root), the second child runs PTRACE_TRACEME, and then the first child drops its privileges. The end result is the parent process can use ptrace to gain control over the first child, which can use ptrace to gain control over the second child — thus letting the attacker gain control over two processes. 

Digging deeper: The system call ptrace (short for “process trace”) allows a parent process to observe and control another process. It’s legitimately used by debuggers and illegitimately used by attackers to “patch” running programs. The parent process starts by having its child process perform PTRACE_TRACEME followed by execve (which hands over control of the process back to the parent). But with this bug, a malicious unprivileged child process can use PTRACE_TRACEME to gain control over a privileged parent process — meaning the attacker can now use ptrace to control a setuid-enabled binary and obtain root privileges.

Yes, but: Exploiting this bug assumes a few things that aren’t necessarily realistic. First, the attacker needs to already have access to their target. Anyone looking to exploit this bug would also need to exploit another bug first to get their malicious code onto the target system. Second, this requires the target to have ptrace capabilities, which things like containers don’t have by default.

The bottom line: There is no reason to hit the panic button. There is an upstream patch for the Linux kernel, but as of today, there are no patches from Debian, Red Hat Enterprise Linux, or Ubuntu. Still, the attacker would need another exploit first to gain access to their target before exploiting this bug, and the bug doesn’t apply to systems without ptrace capabilities (like containers).

For Capsule8 customers, you can chill back and relax, since this is caught by our Stack Pivot, Ptrace, Program (for pkexec), Set Privilege, and Interactive Shell detection strategies by default (some would say it’s overkill, but that’s how we roll).

The Capsule8 Labs team conducts offensive and defensive research to understand the threat landscape for modern infrastructure and to continuously improve Capsule8’s attack coverage.