Matasano Advisory: MacOS X Mach Exception Server Privilege Escalation
Dino Dai Zovi | September 29th, 2006 | Filed Under: Apple, New Findings
Release Date: Fri Sep 29 2006
Synopsis
MacOS X uses Mach exception ports to support the CrashReporter “Application Quit Unexpectedly” dialog, Problem Report dialog, process debugging, and crash dumps logs.
On vulnerable operating systems, attackers can exploit the inheritance of Mach exception ports to inject code into SUID processes, allowing nonprivileged users to assume root privileges.
Background
In Mach, tasks communicate with each other through the basic IPC primative, Mach Ports [1]. Ports are the basis of Mach RPC and are also used to identify and communicate with other tasks and threads. The Mach security model is based on “port rights”, the right to send and/or receive messages on these ports. Having port send rights to another task port allows one to fully control that task by reading/writing its memory and controlling threads belonging to that task. A special type of port, exception ports [2], allow another task to be notified when a process generates a hardware or software exception.
In a Mach-based Unix operating system, each Unix process has a number of default ports that allow it to communicate with other tasks, including the kernel and its parent process. Under MacOS X, the exception ports are usually set to a port owned by crashreporterd so that it can generate crash logs when an application crashes.
A number of MacOS X kernel vulnerabilities have been discovered by exploiting the difference between the Unix and Mach security models. Mach, for instance, has no notion of setuid processes or even users for that matter. Obtaining port send rights to the task or thread port for a process you don’t own gives you complete control over that process. This vulnerability in the MacOS X Mach exception handling that allows just that.
MacOS X includes a number of kernel-based Mach RPC servers. One such
server is the Mach Exception Server (exc_server). The Exception
Server decodes exception messages from a Mach task and dispatches the
exception to callback functions defined in the caller.
The exception handling callbacks are called with the Mach
ports of the task and thread where the exception occurred as parameters and have send rights
granted on those ports.
A number of Mach-based Unix operating systems (including MacOS X and
OpenStep) allow SUID executables to inherit the parent processes’
exception ports. When an exception notification is received, the
parent calls the kernel exception server exc_server() to process the
exception and call any of a set of defined callback functions. The
catch_exception_raise() callback is given Mach port send rights to the
Mach thread that generated the exception and the task containing the
thread. These rights allow the parent to modify the thread’s context and the
task’s address space. A parent process may exploit this by allocating
memory in the child task’s address space, copying in executable code,
and causing a thread in the task to execute the injected code.
Exploiting this vulnerability requires a SUID root executable that can
forced to generate an exception. A number of common setuid root
binaries like /usr/bin/at or /usr/bin/rlogin crash when executed with
a NULL argv pointer, and this suffices to enable exploitation of this
vulnerability.
Target
This vulnerability has been exploited on MacOS X 10.4 and 10.3 and verified to exist on OpenStep 4.2. It is assumed that releases of MacOS X prior to 10.3 are also vulnerable, as well as earlier releases of OpenStep and NeXTSTEP.
Impact
Unprivileged attackers with local access can obtain root credentials.
Vendor Response
Apple has resolved this vulnerability as of MacOS X 10.4.8.
Workarounds
As this vulnerability exists in the operating system kernel, there are no known workarounds.
Origin
Dino Dai Zovi, Matasano Security
ddz at matasano.com
For more information on this advisory, please contact
advisories at matasano.com
References
[1] J. Boykin, D. Kirschen, A. Langerman, and S. LoVerso. Programming under Mach. Addison-Wesley, 1993.
[2] David L. Black, et al. “The Mach Exception Handling Facility”


ilja
October 2nd, 2006 12:04 amthere’s been a public exploit out for this bug for about a year I think. Nice apple finally fixed it
Dino
October 2nd, 2006 10:12 amHello Ilja,
I wouldn’t be surprised if there are some way older slightly less-than-public exploits for it also, the bug has been around for a long while. Once I get NeXTSTEP 3.3 running in a VM, I’ll see if they had the bug also :).
Nate
October 2nd, 2006 10:44 amVendor disclosure’s not broken!
Steve Christey
October 2nd, 2006 2:59 pmGreat work. Privilege chaining issues are cool.
rjohnson
October 3rd, 2006 12:30 amNemo published some related work in Uninformed back in March. He did a good job of explaining the core fundamentals of the Mach subsystem in OSX and demonstrated various methods of subverting the BSD security features using the Mach subsystem. Definitely a good read.
Apple Bugs’ Hunting at www.ikiblogku.com
February 7th, 2008 8:41 pm[…] the way the Apple security community is thingking. One finding by Dino Zaovi, as in the link below, http://www.matasano.com/log/530/matasano-advisory-macos-x-mach-exception-server-privilege-escalation... […]
Leave a reply