Heap Spraying: The IE createTextRange() exploit

In My opinion, the IE createTextRange() exploit is one of the most simple exploit that use heap spraying technique. We just call document.getElementById('some_input_id').createTextRange() or we create an element by call document.createElment("input") function and then call createTextRange() - IE will be crashed in both cases.

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"
  

I decide to inject more heap into the memory to get more information about its behavior. I inject 20 chunks at this time and I got the result:

• most of injected heap is in 0x06xxxxxx and 0x07xxxxxx address range
• the exploit takes more time to execute than the first time
  

Again.. I increase the number of chunk to 100:

• 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

Heap Spraying: Introduction

In past several months, Heap spraying has become one of the most prevalent technique to exploit vulnerability in browser. IE “createTextRange()” and Mozilla Firefox “InstallVersion.compareTo()” are the examples of this technique. Because it is undocumented technique – actually not well document, I decide to start to study what is it and how it work.

This technique was introduced by hacker named “SkyLined”. He used Heap Spraying technique to attack the vulnerability in IE, MS04-040 and MS05-020. However I also found the technique like heap spraying, it was mentioned in Microsoft Internet Information Services Remote Buffer Overflow.

After I had read these exploit codes, I got some point about this technique. Heap spraying is used when the vulnerable program (IE, Firefox in this case) call or jmp into invalid memory. This invalid memory must be in the possible heap range address - not in DLL virtual address, PEB, TEB, etc. And it must not higher than 0x7fffffff because above this address is kernel address space. See
Windows Memory Layout for detail. This is one of the limitation of heap spraying technique.

So, what can we do if it jumps into the possible heap range but invalid memory? The answer depends on the nature of the vulnerable program. If we can't control (actually "injected") the application's heap - Gave Over. But if we can, we will inject heap as much as possible until the invalid memory become the valid memory. Sure, the injected heaps contain our nop + shellcode, so the vulnerable program will landing on our nop and shellcode :) That's why this technique is called "Heap Spraying"

Now, I got another limitation of this technique - we have to able to control the application's heap. As I known, there are few applications that we are able to control heap. Web browser is the one of these - inject heap via JavaScript

I also create a simple picture to demonstrate the basic concept about it. Here's the picture.

Even though heap spraying concept is the simple one, its implementation quite complex. There are many things I must to find out...

Welcome to Freedom 's blog

Welcome to Freedom's blog !! This blog is all about exploitation techniques. I reproduce these entries from my space, but in English. At this time, I focus on Heap Spraying technique and I will note the detail about it soon.