Monday, November 26, 2007

New RTSP Quicktime flaw affects both OSX and Windows

Apple’s unsafe and cavalier attitude towards security puts not only Macintosh users at risk, but also Windows users. The latest QuickTime flaw demonstrates this. QuickTime is Apple’s multimedia player. It’s the part of iTunes that plays the music/videos, although you can install it separately without iTunes. Windows users who have iPods or attempt to play “.mov” videos will likely have QuickTime installed.

QuickTime is written in an inherently insecure manner. This puts at risk anybody who uses it, Windows or Macintosh. There have been a constant stream of bugs in QuickTime published over the last couple years, such as the famous 0day that won a Hack the Mac contest.

Address Space Layout Randomization

The most interesting bit of these latest QuickTime vulnerabilities is how they react with “Address Space Layout Randomization” or “ASLR”. ASLR is a technique of mixing things up in memory so that hackers cannot find them. This is armor that prevents vulnerabilities from being exploited in practice.

Apple announced ASLR as a feature in their latest version of the operating system, Mac OS X 10.5 (TigerLeopard). However, Apple largely lied. While some insignificant items were indeed randomized, nothing that hackers are interested in where changed. If Apple had fully randomized things like Windows Vista, then this QuickTime vulnerability would (likely) not be exploitable.

Does this mean that this vulnerability is not exploitable on Vista version of QuickTime? Humorously, Apple still has a problem here. Vista ASLR requires a little cooperation from developers. Developers have to link their code with the flag /dynamicbase. This sets a bit in their compiled code that tells Vista it can randomize the layout of memory. Apple developers do not set that all-important flag, telling Vista NOT to randomize their layout.

Even though Apple didn’t set it, you can set that flag yourself. It’s just a single bit within the DLL file. If you flip that bit, then Vista will load QuickTime in a randomized fashion. As far as we can tell, QuickTime runs just fine under Vista with the ASLR bit set.

The original location of QTOControl.dll.

What it look like in PE Explorer.

After its been modified save and copy it back. (note that Vista requires admin privs to copy the file)

The new location of QTOControl.dll.

Watching a video.

QuickTime has multiple executables, all of which must be changed in this manner. We set this bit on all the DLLs, then tried the latest QuickTime exploits. As we expected, setting the flag stops the exploits from working, protecting the system.

Changing a major application like QuickTime is not as easy as snapping your fingers, but Vista has been out almost a year now so it seems like support should have trickled down now. Apple should have enabled randomization in QuickTime.

RTSP handler

The easiest way to exploit QuickTime was URLs that caused it to be executed directly. Both IE7 and Firefox have removed the rtsp:// handler. This makes it harder to reach QuickTime. Users must manually download a QuickTime file and play it, rather than simply following a link. When trying to play QuickTime files, Vista will warn the user that they may be accessing malicious content.
Below is what message I get while trying diffrent attack methods via Firefox.

Unfortunately, Safari still supports the rtsp:// handler, meaning they are at much greater risk than IE/Firefox users.

The Proof of Concept (PoC) Exploit

Below is a screen shot of gdb attach to the QuickTime Player after the exploit was successful. It is crashing because of an attempt to dereference EAX, which is 0x41414141. You can see in the instruction before EIP that EAX is loaded from a deference of EBP+0x10. Looking at EBP the pad the author of the PoC chose, 0x41, can clearly been seen.

Tracking down this bug is easy considering the information given by the PoC author about it being a stack overflow. The problem is a lack of length checking in the _EngineNotificationProc before calling a function called BlockMoveData. BlackMoveData is just a wrapper for bcopy(), a notorious bad function from a security standpoint.

Microsoft has impressed the security community with its dedication to secure coding practice. It bans dangerous functions like bcopy(), and forces its programmers to use safer versions (such as memcpy_s(),the safer version of bcopy()). Apple has not adopted secure coding practices; they still use known dangerous code such as bcopy(), sprintf(), strcpy(), and so on.

Breaking on the _EngineNotificationProc.

(gdb) set disassembly-flavor intel
(gdb) break _EngineNotificationProc
Breakpoint 1 (_EngineNotificationProc) pending.
(gdb) attach 316
Attaching to process 316.
Reading symbols for shared libraries . done
Breakpoint 1 at 0x174816fd
Pending breakpoint 1 - "_EngineNotificationProc" resolved
0x93442446 in GIF_CDBandDecompress ()
(gdb) c

Tracing the bad data.

0x174329bc in INet_GetFieldBody ()
1: x/i $eip 0x174329bc : mov edx,eax
(gdb) x/20x $ebp
0xbfffc908: 0xbfffcbc8 0x174820d8 0x17bdb811 0x00001447
0xbfffc918: 0x175732d5 0x15af8808 0x00000000 0x69746c32
0xbfffc928: 0x0000bd7e 0x00000000 0x00000012 0x00000010
0xbfffc938: 0xbfffc948 0x92d90000 0x00000012 0x00000006
0xbfffc948: 0xbfffc958 0x00200020 0x00000000 0x0083f69c
(gdb) info registers
eax 0x17bdb837 398309431
ecx 0x0 0
edx 0x15 21
ebx 0x17481708 390600456
esp 0xbfffc8e0 0xbfffc8e0
ebp 0xbfffc908 0xbfffc908
esi 0x17bdb811 398309393
edi 0x15af8808 363825160
eip 0x174329bc 0x174329bc
eflags 0x286 646
cs 0x17 23
ss 0x1f 31
ds 0x1f 31
es 0x1f 31
fs 0x0 0
gs 0x37 55
(gdb) x/20x $eax
0x17bdb837: 0x70737472 0x302f2f3a 0x302e302e 0x312f302e
0x17bdb847: 0x33706d2e 0x430a0d2f 0x65746e6f 0x542d746e
0x17bdb857: 0x3a657079 0x41414120 0x41414141 0x41414141
0x17bdb867: 0x41414141 0x41414141 0x41414141 0x41414141
0x17bdb877: 0x41414141 0x41414141 0x41414141 0x41414141
(gdb) x/20s $eax
0x17bdb837: "rtsp://\r\nContent-Type: ", 'A' ...
0x17bdb8ff: 'A' ...
0x17bdb9c7: 'A' ...
0x17bdba8f: 'A' ...
0x17bdbb57: 'A' ...
0x17bdbc1f: 'A' , 'B' ...
0x17bdbce7: 'B' ...
0x17bdbdaf: 'B' ...
0x17bdbe77: 'B' ...
0x17bdbf3f: 'B' ...
0x17bdc007: 'B' ...
0x17bdc0cf: 'B' ...
0x17bdc197: 'B' ...
0x17bdc25f: 'B' ...
0x17bdc327: 'B' ...
0x17bdc3ef: 'B' ...
0x17bdc4b7: 'B' ...
0x17bdc57f: 'B' ...
0x17bdc647: 'B' ...
0x17bdc70f: 'B' ...

The guilty system call.

1: x/i $eip 0x1748216f <_enginenotificationproc+2680>: mov DWORD PTR [esp+0x4],edx
0x17482173 in _EngineNotificationProc ()
1: x/i $eip 0x17482173 <_enginenotificationproc+2684>: mov DWORD PTR [esp],eax
0x17482176 in _EngineNotificationProc ()
1: x/i $eip 0x17482176 <_enginenotificationproc+2687>: call 0x175812ae
(gdb) x/20x $eax
0x17bdb85c: 0x41414141 0x41414141 0x41414141 0x41414141
0x17bdb86c: 0x41414141 0x41414141 0x41414141 0x41414141
0x17bdb87c: 0x41414141 0x41414141 0x41414141 0x41414141
0x17bdb88c: 0x41414141 0x41414141 0x41414141 0x41414141
0x17bdb89c: 0x41414141 0x41414141 0x41414141 0x41414141
(gdb) x/20x $edx
0xbfffca99: 0x1f000016 0x6c000000 0x00000006 0xa8000000
0xbfffcaa9: 0x0f001201 0x6c92dbbc 0x000083f6 0x5800000c
0xbfffcab9: 0x2517bdcc 0x009494bd 0x00000000 0x08000000
0xbfffcac9: 0x7abfffcb 0x009494bd 0xe0001200 0xa815ae1f
0xbfffcad9: 0x04000001 0x00000400 0x9317b7ba 0xa8175712
(gdb) info registers
eax 0x17bdb85c 398309468
ecx 0x0 0
edx 0xbfffca99 -1073755495
ebx 0x17481708 390600456
esp 0xbfffc910 0xbfffc910
ebp 0xbfffcbc8 0xbfffcbc8
esi 0xffffeae6 -5402
edi 0xbfffcd38 -1073754824
eip 0x17482176 0x17482176 <_enginenotificationproc+2687>
eflags 0x286 646
cs 0x17 23
ss 0x1f 31
ds 0x1f 31
es 0x1f 31
fs 0x0 0
gs 0x37 55


Installing Apple code on a Microsoft Vista system will make that system unsafe. Since these QuickTime vulnerabilities are equally exploitable on both Vista and Mac OS X 10.5, the fans might conclude that both operating systems are equally safe. This is not true, Vista is vastly more secure than the Macintosh. Apple’s only advantage over Microsoft is their small market share, which means hackers are less interested in them. However, as hackers are having a harder time cracking Vista, they are getting more interested in the Mac, and we are seeing more exploits and more malware targeting Apple users.

As always there is more information in the Hacker Eye View report concerining these issuses.


Jeff said...

Just a minor nit, and doesn't really negate any of your criticisms, but 10.5 is leopard, not tiger.r).

David Maynor said...

Indeed, its been corrected.

Jeff said...

Good point though, ASLR is not exactly cutting edge anymore and it's amazing that Apple has been so slow to adopt it, even while their marketing lambasts Microsoft's security track record despite the tremendous strides they've taken recently.

I definitely dig what Apple is doing for usability, but it'd be nice if they approached security with that same level of rigor.

On a related note, have you done any testing of ASLR usage or lack of usage in Leopard's base apps, and other recent apple apps? (Specifically iLife, iWork, etc.. the stuff most likely to be on Leopard machines.)

I'm sure you're already seen Thomas Ptacek's first impressions of Leopard security over on the Matasano blog, but he doesn't discuss ASLR much.. seems he's not sold on it's merits. I'd be interested to hear your opinion on the subject...

Robert Graham said...

I'd be interested to hear your opinion on the subject... (of Mac's ASLR)

Apple doesn't implement ASLR in Leopard as they claim.