OS X privilege escalation. The slow way.

»patient0 is a toolkit for creating system-wide, run-time process infection with the purpose of exploring OS X's trust model.

patient0 provides both a means of infecting processes with custom code and a supporting functionality to make writing custom code, or pathogens, easier. The main idea behind patient0 is that there are a few main processes on a OS X desktop which are used to start software: Dock, Finder, and SystemUIServer. If these three processes carry a payload to be delivered to every process launched, they can act as a highly contagious patient 0 for a given system pathogen.

patient0 does not require any local file system write access to spread and will only leave traces on a system in active memory and in any swapped out memory (to disk for sleep or disuse). In addition, patient0 and its pathogens are packaged as Mach-O bundles which means that they can load and use any available system libraries ranging from SystemB to frameworks like Cocoa and Tcl.

patient0 came about from the realization that much of OS X Leopard's end user security comes from relying on user-level processes. User authorization tokens are granted to unprivileged processes (Software Update, Preferences Panes, etc) which can in turn be used to perform privileged actions. For example, it's possible to remove package validation from Software Update or to pivot a pathogen infection from the user-privilege level to the root-owned launchd process (pid 1) using the authorization token supplied during a Preferences Pane unlock. All of this can be done without even trying to perform direct social engineering attacks on a user (like falsified authorization dialogs) because the code is running _as_ the user-trusted process.

There are any number of possible mitigation techniques for this class of attack, ranging from automatically reissuing kernel task ports on exec*() calls (as is done with setuid apps) to enforcing signed code path access to Security framework calls using something like taskgated (seriously non-trivial). Of course, the easy way out is to move all the authentication work into setuid co-processes, but, of course, that leaves more open attack surface for direct root compromises.

This page does not necessarily reflect the views of my employer or anyone I'm associated with.