Heap Spraying: The IE createTextRange() exploit
I try to create a small HTML file to test this vulnerability.
x = document.createElement("input");
x.type = "image";
y = x.createTextRange();
I attach IE with WinDbg and browse this page. This is the result:
IE crashs because of access violation - eip point to the address 0x3c0474c2. I have tested many times and IE still crashs at 0x3c0474c2 eventhough I open others application at the same time. I think this is the deterministic behavior of this vulnerability - may be useful for exploitation.
I begin to exploit the vulnerability by modify SkyLined's code and integrate it into my code. First of all, I wanna to know where is my injected heap. I inject 10 chunk of heap fill with nop + shellcode into the memory. After IE crash, I examine all heaps and I found this:
- 1 injected heap is in address range 0x01xxxxxx
- 2 injected heaps are in address range 0x02xxxxxx
- 7 injected heaps are in address range 0x06xxxxxx
- 1 injected heap is is address range 0x07xxxxxx
- first 4 bytes in each heap is the offset to last 4 bytes in heap
- all of injected heaps are in "Virtual Block"
- most of injected heap is in 0x06xxxxxx and 0x07xxxxxx address range
- the exploit takes more time to execute than the first time
- most of injected heap is in 0x0axxxxxx and 0x0bxxxxxx address range
- the exploit takes more time to execute than the second time
As you can see, everytime I increase number of chunk, the address of injected heap is also increased. If I try to increase number of chunk until the address 0x3c0474c2 is in range of injected heap, what will be happened ? lol.
I try o increase number of chunk until 1700 chunks, there is something different from the past:
WinDbg show that IE reachs the break instruction, cc command - out shellcode, at 0x3c07000e instead of 0x3c0474c2. Our payload got execute at the address that higher than 0x3c0474c2 !? This means that we can past the point that IE had crashed before. I view at the address 0x3c0474c2 and I found that it was filled with our nop - 0x90
In this situation, I can conclude that IE had crash and land at 0x3c0474c2, our nop, and it execute our nop until reach our payload at 0x3c07000e, cc instruction.
Wow, our exploit was written in few hours. I have tried serveral times to ensure that the number 1700 is ok. Changing payload from "cc" instruction to "port binding" shellcode or "reverse connect" shellcode is also ok.
P.S. - Tested on Windows XP Professional Service Pack 2 and Internet Explorer 6.0