MOAB-20-01-2007: Apple iChat aim:// URL Handler Format String Vulnerability

Summary

Description from the Wikipedia article:

AOL Instant Messenger (AIM), ICQ, .Mac and Jabber client for Mac OS X. Using a Jabber-like protocol and Bonjour for user discovery, it also allows for LAN communication. iChat's AIM support is fully endorsed by AOL, and uses their official implementation of the AIM OSCAR protocol. Using a Jabber transport, iChat users may also integrate their MSN and Yahoo! contacts into the Jabber pane. 

Apple iChat AIM URI scheme (referred as the 'url handler') handling is affected by a classic format string vulnerability, allowing remote users to cause a denial of service condition or arbitrary code execution. This can be triggered via simple HTML anchors, using Flash or Javascript for automating the process (ex. against Safari users).
Affected versions

This issue has been verified in Apple iChat version 3.1.6 (v441). Previous versions might be affected.
Proof of concept, exploit or instructions to reproduce

The proof of concept uses Javascript to trigger the issue. It will work out of the box for Safari, and will cause Firefox to open a dialog asking for user confirmation.
Debugging information

The following debugging information shows iChat triggering the issue via the provided Javascript-based proof of concept:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x9000c0c1 in __vfprintf ()
(gdb) i r
eax 0x0 0
ecx 0x0 0
edx 0x0 0
ebx 0x9000ad62 -1879003806
esp 0xbfffd360 0xbfffd360
ebp 0xbfffdab8 0xbfffdab8
esi 0xbfffeaae -1073747282
edi 0x25 37
eip 0x9000c0c1 0x9000c0c1 <__vfprintf+4976>
eflags 0x10286 66182
cs 0x17 23
ss 0x1f 31
ds 0x1f 31
es 0x1f 31
fs 0x0 0
gs 0x37 55

(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 0x000da226 in ?? ()
#7 0x000bfbb6 in ?? ()
#8 0x90a58c56 in objc_msgSendv ()
#9 0x925f443e in -[NSInvocation invoke] ()
#10 0x9264174f in -[NSConnection dispatchInvocation:] ()
#11 0x9263fb51 in -[NSConnection handleRequest:sequence:] ()
#12 0x9263f3ae in -[NSConnection handlePortCoder:] ()
#13 0x9263efef in -[NSConcretePortCoder dispatch] ()
#14 0x9263ea4c in __NSFireMachPort ()
#15 0x9083a3c5 in __CFMachPortPerform ()
#16 0x9082a66d in CFRunLoopRunSpecific ()
#17 0x90829b0e in CFRunLoopRunInMode ()
#18 0x92dc9bef in RunCurrentEventLoopInMode ()
#19 0x92dc92fd in ReceiveNextEventCommon ()
#20 0x92dc9154 in BlockUntilNextEventMatchingListInMode ()
#21 0x9326e465 in _DPSNextEvent ()
#22 0x9326e056 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#23 0x93267ddb in -[NSApplication run] ()
#24 0x9325bd2f in NSApplicationMain ()
#25 0x00002b6e in ?? ()
#26 0x0007e63d in ?? ()

Read the 'exploitation conditions' section for information on why it's dereferencing a NULL pointer and what implications this may have in the context of this particular issue.
Notes
Exploitation conditions

Currently, due t the lack of support for %n (see the Colloquy related advisory), exploitation for arbitrary code execution is certainly more difficult. Although, we can write NULL bytes to any memory location, and this can be useful in certain conditions, specially when we are able to 'spray' the heap with our own data. We are investigating some possibilities around these issues that could make them reliable for code execution. Stay tuned…
Workaround or temporary solution

Disable the aim:// URL handler via RCDefaultApp.