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”

6 Comments so far

  • ilja

    October 2nd, 2006 12:04 am

    there’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 am

    Hello 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 am

    Vendor disclosure’s not broken!

  • Steve Christey

    October 2nd, 2006 2:59 pm

    Great work. Privilege chaining issues are cool.

  • rjohnson

    October 3rd, 2006 12:30 am

    Nemo 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