Software Vulnerability Exploitation Blog

Wednesday, July 05, 2006

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%.


Post a Comment

<< Home