Corelan Cybersecurity Research

01561438 0061 0201 [00] 01561440 00300 - (busy) 
01561740 0061 0061 [00] 01561748 00300 - (busy) 
01561a48 00b3 0061 [00] 01561a50 00590 - (free)

Great, but we have not been really using the FreeList mechanisms of the BEA at this point.   All we have been doing is allocate chunks from within a normal segment, consuming the free space that was there all the time.   To trigger the BEA FreeList mechanism and see how it behaves, we’ll have to "free" some chunks ourselves first.

BEA_Alloc2

In this second example, we’ll create a series of allocations of 0x300 bytes.   We’ll free the last one and then cause 2 allocations of 0x100 bytes. 

The purpose of the exercise is to check where these 2 allocations will be placed. 

As we intend to evaluate the BEA mechanism, we have to avoid that the LFH gets triggered.  We know that the heap manager in Windows 7 will trigger the LFH when it sees 18 consecutive allocations of a size in the same bucket (i.e. the next request will be allocated from within a LFH managed subsegment).

For that reason, we’ll only cause 10 allocations of 0x300 bytes, hopefully avoiding that the LFH will be used.

After causing the 10 allocations, let’s examine the last one and see if LFH is on or off.

App:

C:\Users\corelan\Desktop\vc++\win10\BEA_Alloc2\Release>BEA_Alloc2.exe
Default process heap found at 0x009B0000
Press a key to start...
Allocated chunk of 0x300 bytes at 0x009BF1D0
Allocated chunk of 0x300 bytes at 0x009BF4D8
Allocated chunk of 0x300 bytes at 0x009BF7E0
Allocated chunk of 0x300 bytes at 0x009BFAE8
Allocated chunk of 0x300 bytes at 0x009BFDF0
Allocated chunk of 0x300 bytes at 0x009C00F8
Allocated chunk of 0x300 bytes at 0x009C0400
Allocated chunk of 0x300 bytes at 0x009C0708
Allocated chunk of 0x300 bytes at 0x009C0A10
Allocated chunk of 0x300 bytes at 0x009C0D18

Press return to continue

WinDBG:

0:003> !heap -x 0x009C0D18
Entry     User      Heap      Segment       Size  PrevSize  Unused    Flags
-----------------------------------------------------------------------------
009c0d10  009c0d18  009b0000  009b0000       308       308         8  busy

Free chunk at 0x009C0D18
Press return to continue

0:003> !heap -x 0x009C0D18  
Entry     User      Heap      Segment       Size  PrevSize  Unused    Flags
-----------------------------------------------------------------------------
009c0d10  009c0d18  009b0000  009b0000      12d0       308         0  free 

Before running the rest of the application, let’s look at the current state of the heap, looking for "free" chunks of 0x300 bytes or larger.  The output below only contains the relevant lines:

WinDBG:

0:003> !heap -p -h 0x009B0000
_HEAP @ 9b0000
_LFH_HEAP @ 610000
_HEAP_SEGMENT @ 9b0000
CommittedRange @ 9b0498
HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
009c0d10 025a 0061  [00]   009c0d18    012c8 - (free)

0:003> !heap -p -h 0x009B0000  
    _HEAP @ 9b0000  
      _LFH_HEAP @ 610000
      _HEAP_SEGMENT @ 9b0000
       CommittedRange @ 9b0498  
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        009b2b00 0021 0012  [00]   009b2b08    00100 - (free)
        009bc330 0034 0089  [00]   009bc338    00198 - (free)
        009c0d10 025a 0061  [00]   009c0d18    012c8 - (free)

Allocated chunk of 0x100 bytes at 0x009B2B08
Allocated chunk of 0x100 bytes at 0x009BC338
Done...

BEA_Alloc3

C:\Users\corelan\Desktop\vc++\win10\BEA_Alloc3\Release>BEA_Alloc3.exe 
    
Default process heap found at 0x016C0000 
Press a key to start...
Allocated chunk of 0x58 bytes at 0x016C96D0     
Allocated chunk of 0x100 bytes at 0x016C2B08 
Allocated chunk of 0x58 bytes at 0x016CDF50 
Allocated chunk of 0x100 bytes at 0x016CD328 
Allocated chunk of 0x58 bytes at 0x016CD430 
Allocated chunk of 0x100 bytes at 0x016CFFF8 
Allocated chunk of 0x58 bytes at 0x016C2CB8 
Allocated chunk of 0x100 bytes at 0x016D0100 
Allocated chunk of 0x58 bytes at 0x016CDC18 
Allocated chunk of 0x100 bytes at 0x016D0208 
Allocated chunk of 0x58 bytes at 0x016CDC78 
Allocated chunk of 0x100 bytes at 0x016D0310 
Allocated chunk of 0x58 bytes at 0x016D0418 
Allocated chunk of 0x100 bytes at 0x016D0478 
Allocated chunk of 0x58 bytes at 0x016D0580 
Allocated chunk of 0x100 bytes at 0x016D05E0 
Allocated chunk of 0x58 bytes at 0x016D06E8 
Allocated chunk of 0x100 bytes at 0x016D0748 
Allocated chunk of 0x58 bytes at 0x016D0850 
Allocated chunk of 0x100 bytes at 0x016D08B0 

Press return to continue

0:003> !heap -x 0x016D08B0 
    
Entry User Heap Segment Size PrevSize Unused Flags 
----------------------------------------------------------------------------- 
016d08a8 016d08b0 016c0000 016c0000 108 60 8 busy

0:003> !heap -x 0x016D0850     
Entry User Heap Segment Size PrevSize Unused Flags 
----------------------------------------------------------------------------- 
016d0848 016d0850 016c0000 016c0000 60 108 8 busy

Allocated chunk of 0x100 bytes at 0x016D09B8 
Allocated chunk of 0x58 bytes at 0x016D0AC0, filled with 'A' 
Allocated chunk of 0x100 bytes at 0x016D0B20 

Press return to continue
  

Great! We can use WinDBG to confirm that the 3 chunks are adjacent indeed, and that the middle chunk (0x58) is filled with A’s

(from output of !heap -p -h 0x016C0000)

016d09b0 0021 0021 [00] 016d09b8 00100 - (busy)    
016d0ab8 000c 0021 [00] 016d0ac0 00058 - (busy)
016d0b18 0021 000c [00] 016d0b20 00100 - (busy)
0:001> dd 0x016d0ac0 L 0x58/4     
016d0ac0 41414141 41414141 41414141 41414141 
016d0ad0 41414141 41414141 41414141 41414141 
016d0ae0 41414141 41414141 41414141 41414141 
016d0af0 41414141 41414141 41414141 41414141 
016d0b00 41414141 41414141 41414141 41414141 
016d0b10 41414141 41414141
  

Next, the 0x58 byte chunk will be freed (which means it should end up on the freelist, and not merged with an adjacent free chunk as long as we don’t free the adjacent 0x100 byte chunks ourselves).  Finally, a new allocation request for 0x58 is supposed to take that position back.  The example application will populate it with B’s:

App:

Free chunk of 0x58 bytes at 0x016D0AC0 
Allocated chunk of 0x58 bytes at 0x016D0AC0, filled with 'B' 
    
Done...    

WinDBG:

0:001> dd 0x016d0ac0 L 0x58/4     
016d0ac0 42424242 42424242 42424242 42424242 
016d0ad0 42424242 42424242 42424242 42424242 
016d0ae0 42424242 42424242 42424242 42424242 
016d0af0 42424242 42424242 42424242 42424242 
016d0b00 42424242 42424242 42424242 42424242 
016d0b10 42424242 42424242

Bingo.

BEA_Alloc4

Let’s take it one step further.

This time we’ll free a 0x58 byte chunk, and we’ll try to use a 0x80 byte allocation (where we only control the last 4 dwords), to control the exact 4 first dwords in the original 0x58 byte chunk. (I know, replacing one object with another object of a different size sounds kinky… but hey, who knows this could be useful one time … or not)

C:\Users\corelan\Desktop\vc++\win10\BEA_Alloc4\Release>BEA_Alloc4.exe
Default process heap found at 0x010D0000
Press a key to start...
<...snip...>
    
Allocated chunk of 0x68 bytes at 0x010E1D68
Allocated chunk of 0x58 bytes at 0x010E1DD8
Allocated chunk of 0x80 bytes at 0x010E1E38
Allocated chunk of 0x68 bytes at 0x010E1EC0
Allocated chunk of 0x58 bytes at 0x010E1F30
Allocated chunk of 0x80 bytes at 0x010E1F90
Allocated chunk of 0x68 bytes at 0x010E2018

Press return to continue

Allocated start chunk (0x80 bytes) at 0x010E2088  
Allocated first chunk (0x68 bytes) at 0x010E2110
Allocated second 'vulnerable' chunk (0x58 bytes) at 0x010E2180, filled with 'A'
Allocated end chunk (0x80 bytes) at 0x010E21E0
Press return to continue

        010e2080 0011 000e  [00]   010e2088    00080 - (busy)    
        010e2108 000e 0011  [00]   010e2110    00068 - (busy)
        010e2178 000c 000e  [00]   010e2180    00058 - (busy)
        010e21d8 0011 000c  [00]   010e21e0    00080 - (busy)

Free chunk of 0x58 bytes at 0x010E2180
Free first chunk of 0x68 bytes at 0x010E2110
  
Press return to continue

 0:003> !heap -p -a 0x010E2110
    address 010e2110 found in  
    _HEAP @ 10d0000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        010e2108 001a 0000  [00]   010e2110    000c8 - (free)
0:003> dd 0x010E2110 L 0xc8/4
010e2110  010e2268 010de858 00000000 00000000  
010e2120  00000000 00000000 00000000 00000000
010e2130  00000000 00000000 00000000 00000000
010e2140  00000000 00000000 00000000 00000000
010e2150  00000000 00000000 00000000 00000000
010e2160  00000000 00000000 00000000 00000000
010e2170  00000000 00000000 0c00000c 00008812
010e2180  010e2268 010de858 41414141 41414141
010e2190  41414141 41414141 41414141 41414141
010e21a0  41414141 41414141 41414141 41414141  
010e21b0  41414141 41414141 41414141 41414141
010e21c0  41414141 41414141 41414141 41414141
010e21d0  41414141 41414141

  
Allocated chunk of 0x80 bytes at 0x010E2110, filled with 'B'
  
Done...

  
0:001> !heap -p -a 0x010E2110
    address 010e2110 found in
    _HEAP @ 10d0000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        010e2108 0011 0000  [00]   010e2110    00080 - (busy)

  
0:001> dd 0x010E2110 L 0xc8/4
010e2110  42424242 42424242 42424242 42424242
010e2120  42424242 42424242 42424242 42424242
010e2130  42424242 42424242 42424242 42424242
010e2140  42424242 42424242 42424242 42424242
010e2150  42424242 42424242 42424242 42424242
010e2160  42424242 42424242 42424242 42424242
010e2170  42424242 42424242 42424242 42424242
010e2180  42424242 42424242 42424242 42424242
010e2190  6a309389 0000880d 010dee10 010d1db8
010e21a0  41414141 41414141 41414141 41414141
010e21b0  41414141 41414141 41414141 41414141  
010e21c0  41414141 41414141 41414141 41414141
010e21d0  41414141 41414141

The Front-End Allocator – LFH

LFH_Alloc1

In this first exercise, we’ll examine if it still takes 0x12 (18) consecutive allocations for a size in the same bucket before the LFH will start taking care of allocations and frees of those sizes.

In order to avoid any influencing or assumptions, I’ll use chunksizes that has not been allocated yet. (0x1500 bytes, 0x2100 bytes, 0x3000 bytes, 0x800 bytes)

I’ll combine a couple of tests in this test:

1. check how many allocations it takes before LFH kicks in
2. see if the LFH trigger is influenced when an allocation happens of a different bucket size during the series of allocations
3. see if the LFH trigger is influenced when a free happens during the allocations, of a chunk in a different bucket/of a different size
4. see if the LFH trigger is influenced when a chunk of the same bucket is freed again, during the series of allocations

Step1: how many allocations are needed to trigger LFH

App:

C:\Users\corelan\Desktop\vc++\win10\LFH_Alloc1\Release>LFH_Alloc1.exe 
Default process heap found at 0x00D30000 Press a key to start...


[1] Allocated chunk of 0x1500 bytes at 0x00D4CF68
[2] Allocated chunk of 0x1500 bytes at 0x00D4E470 
[3] Allocated chunk of 0x1500 bytes at 0x00D4F978 
[4] Allocated chunk of 0x1500 bytes at 0x00D50E80 
[5] Allocated chunk of 0x1500 bytes at 0x00D52388 
[6] Allocated chunk of 0x1500 bytes at 0x00D53890 
[7] Allocated chunk of 0x1500 bytes at 0x00D54D98 
[8] Allocated chunk of 0x1500 bytes at 0x00D562A0 
[9] Allocated chunk of 0x1500 bytes at 0x00D577A8 
[10] Allocated chunk of 0x1500 bytes at 0x00D58CB0 
[11] Allocated chunk of 0x1500 bytes at 0x00D5A1B8 
[12] Allocated chunk of 0x1500 bytes at 0x00D5B6C0 
[13] Allocated chunk of 0x1500 bytes at 0x00D5CBC8 
[14] Allocated chunk of 0x1500 bytes at 0x00D5E0D0 
[15] Allocated chunk of 0x1500 bytes at 0x00D5F5D8 
[16] Allocated chunk of 0x1500 bytes at 0x00D60AE0 
[17] Allocated chunk of 0x1500 bytes at 0x00D61FE8 
[18] Allocated chunk of 0x1500 bytes at 0x00D6B348 
[19] Allocated chunk of 0x1500 bytes at 0x00D64A20 
[20] Allocated chunk of 0x1500 bytes at 0x00D69E40 
[21] Allocated chunk of 0x1500 bytes at 0x00D6C850 
[22] Allocated chunk of 0x1500 bytes at 0x00D63518 
[23] Allocated chunk of 0x1500 bytes at 0x00D6DD58 
[24] Allocated chunk of 0x1500 bytes at 0x00D67430 
[25] Allocated chunk of 0x1500 bytes at 0x00D6F260 
[26] Allocated chunk of 0x1500 bytes at 0x00D65F28 
[27] Allocated chunk of 0x1500 bytes at 0x00D70768 
[28] Allocated chunk of 0x1500 bytes at 0x00D68938 
[29] Allocated chunk of 0x1500 bytes at 0x00D71C70 
[30] Allocated chunk of 0x1500 bytes at 0x00D77438 
Press return to continue

If you pay close attention to the addresses, you can see a bigger gap between allocations 17 and 18.  This is a good indication that allocations are no longer individual chunks inside a normal segment, but are now being consumed from an LFH subsegment.  To be sure, let’s validate the findings in WinDBG.

Simply run !heap -x  on all addresses (starting from the first one in the list), until you find the first one that has the "LFH" marker.

Allocation 17:

0:001> !heap -x 0x00D61FE8 
Entry User Heap Segment Size PrevSize Unused Flags 
----------------------------------------------------------------------------- 
00d61fe0 00d61fe8 00d30000 00d30000 1508 1508 8 busy

Allocation 18:

0:001> !heap -x 0x00D6B348 
Entry User Heap Segment Size PrevSize Unused Flags 
----------------------------------------------------------------------------- 
00d6b340 00d6b348 00d30000 00d3ae28 1508 - 8 LFH;busy

So – it looks like the LFH takes over with allocation 18.

Step 2: will the LFH trigger be influenced if another allocation (of a size in a different bucket) occurs in the series of 18 allocations.

App:

[1] Allocated chunk of 0x2100 bytes at 0x00D93500 
[2] Allocated chunk of 0x2100 bytes at 0x00D95608 
[3] Allocated chunk of 0x2100 bytes at 0x00D97710 
[4] Allocated chunk of 0x2100 bytes at 0x00D99818 
[5] Allocated chunk of 0x2100 bytes at 0x00D9B920 
[6] Allocated chunk of 0x2100 bytes at 0x00D9DA28 
[7] Allocated chunk of 0x2100 bytes at 0x00D9FB30 
[8] Allocated chunk of 0x2100 bytes at 0x00DA1C38 
[9] Allocated chunk of 0x2100 bytes at 0x00DA3D40 
[10] Allocated chunk of 0x2100 bytes at 0x00DA5E48 
Allocated chunk of 0x300 bytes at 0x00D49450 
[11] Allocated chunk of 0x2100 bytes at 0x00DA7F50 
[12] Allocated chunk of 0x2100 bytes at 0x00DAA058 
[13] Allocated chunk of 0x2100 bytes at 0x00DAC160 
[14] Allocated chunk of 0x2100 bytes at 0x00DAE268 
[15] Allocated chunk of 0x2100 bytes at 0x00DB0370 
[16] Allocated chunk of 0x2100 bytes at 0x00DB2478 
[17] Allocated chunk of 0x2100 bytes at 0x00DB4580 
[18] Allocated chunk of 0x2100 bytes at 0x00DC10D8 
[19] Allocated chunk of 0x2100 bytes at 0x00DBAAC0 
[20] Allocated chunk of 0x2100 bytes at 0x00DC32E0 
Press return to continue

Focusing on allocation 17 and 18 (of 0x2100 bytes), we can see that alloc 17 was not LFH yet, but the 18th one did it again, despite the allocation of a 0x300 byte chunk in the middle of the series.

0:001> !heap -x 0x00DB4580 
Entry User Heap Segment Size PrevSize Unused Flags 
----------------------------------------------------------------------------- 
00db4578 00db4580 00d30000 00d30000 2108 2108 8 busy

0:001> !heap -x 0x00DC10D8 
Entry User Heap Segment Size PrevSize Unused Flags 
----------------------------------------------------------------------------- 
00dc10d0 00dc10d8 00d30000 00d3ae78 2208 - 3f LFH;busy

Interesting indeed :)

Step 3: will a free (of a different chunk size) influence the LFH trigger ?

App:

[1] Allocated chunk of 0x3000 bytes at 0x00DD6690 
[2] Allocated chunk of 0x3000 bytes at 0x00DD9698 
[3] Allocated chunk of 0x3000 bytes at 0x00DDC6A0 
[4] Allocated chunk of 0x3000 bytes at 0x00DDF6A8 
[5] Allocated chunk of 0x3000 bytes at 0x00DE26B0 
[6] Allocated chunk of 0x3000 bytes at 0x00DE56B8 
[7] Allocated chunk of 0x3000 bytes at 0x00DE86C0 
[8] Allocated chunk of 0x3000 bytes at 0x00DEB6C8 
[9] Allocated chunk of 0x3000 bytes at 0x00DEE6D0 
[10] Allocated chunk of 0x3000 bytes at 0x00DF16D8 
Freed chunk at 0x00D49C80 
Freed chunk at 0x00D4A188 
[11] Allocated chunk of 0x3000 bytes at 0x00DF46E0 
[12] Allocated chunk of 0x3000 bytes at 0x00DF76E8 
[13] Allocated chunk of 0x3000 bytes at 0x00DFA6F0 
[14] Allocated chunk of 0x3000 bytes at 0x00DFD6F8 
[15] Allocated chunk of 0x3000 bytes at 0x00E00700 
[16] Allocated chunk of 0x3000 bytes at 0x00E03708 
[17] Allocated chunk of 0x3000 bytes at 0x00E06710 
[18] Allocated chunk of 0x3000 bytes at 0x00E0C748 
[19] Allocated chunk of 0x3000 bytes at 0x00E15760 
[20] Allocated chunk of 0x3000 bytes at 0x00E1B770 
Done...

WinDBG (focus on allocation 17 and 18 again):

0:001> !heap -x 0x00E06710 
Entry User Heap Segment Size PrevSize Unused Flags 
----------------------------------------------------------------------------- 
00e06708 00e06710 00d30000 00d30000 3008 3008 8 busy
0:001> !heap -x 0x00E0C748 
Entry User Heap Segment Size PrevSize Unused Flags 
----------------------------------------------------------------------------- 
00e0c740 00e0c748 00d30000 00d3aea0 3008 - 8 LFH;busy

Interesting once more:)

Step 4: free a chunk from the same bucket during the allocation series.

[1] Allocated chunk of 0x800 bytes at 0x004EAE70 
[2] Allocated chunk of 0x800 bytes at 0x0053E910 
[3] Allocated chunk of 0x800 bytes at 0x0053F118 
[4] Allocated chunk of 0x800 bytes at 0x0053F920 
[5] Allocated chunk of 0x800 bytes at 0x00540128 
[6] Allocated chunk of 0x800 bytes at 0x00540930 
[7] Allocated chunk of 0x800 bytes at 0x00541138 
[8] Allocated chunk of 0x800 bytes at 0x00541940 
[9] Allocated chunk of 0x800 bytes at 0x00542148 
[10] Allocated chunk of 0x800 bytes at 0x00542950 
Freed chunk at 0x00542950 
[11] Allocated chunk of 0x800 bytes at 0x00542950 
[12] Allocated chunk of 0x800 bytes at 0x00543158 
[13] Allocated chunk of 0x800 bytes at 0x00543960 
[14] Allocated chunk of 0x800 bytes at 0x00544168 
[15] Allocated chunk of 0x800 bytes at 0x00544970 
[16] Allocated chunk of 0x800 bytes at 0x00545178 
[17] Allocated chunk of 0x800 bytes at 0x00545980 
[18] Allocated chunk of 0x800 bytes at 0x009F0070 
[19] Allocated chunk of 0x800 bytes at 0x009F2090 
[20] Allocated chunk of 0x800 bytes at 0x009F68D8 
Done...

WinDBG (looking again at allocation 17 and 18)

0:004> !heap -x 0x00545980 
Entry User Heap Segment Size PrevSize Unused Flags 
----------------------------------------------------------------------------- 
00545978 00545980 00450000 00450000 808 808 8 busy
0:004> !heap -x 0x009F0070 
Entry User Heap Segment Size PrevSize Unused Flags 
----------------------------------------------------------------------------- 
009f0068 009f0070 00450000 00458c60 808 - 8 LFH;busy

Interestingly enough, the free did not really impact the LFH trigger at all.  18 allocations still did the trick.

I guess more exhaustive testing is needed to confirm this behaviour, including checking what happens if there are more frees etc… but at least we are able to see some kind of pattern that indicates it may be more difficult to avoid that the LFH will be get enabled eventually, especially if you have no other option that to cause a certain number of allocations (more than 18) of chunks in the same bucket. 

If you know of a way to prevent this from happening, please let me know :)

LFH_Alloc2

In the second exercise, we’ll see if the LFH still behaves the same way as under Windows 7 – i.e. returning freed chunks in a LIFO manner.   We’ll activate the LFH using 20 allocations of 0x500 bytes.  The last one will be freed, and then another allocation of 0x500 bytes will happen.

The goal is to see if the last one to be freed will be the first one to be returned again. (LIFO).

C:\Users\corelan\Desktop\vc++\win10\LFH_Alloc2\Release>LFH_Alloc2.exe 
Default process heap found at 0x008D0000 
Press a key to start...
[1] Allocated chunk of 0x500 bytes at 0x008E0440 
[2] Allocated chunk of 0x500 bytes at 0x008E0948 
[3] Allocated chunk of 0x500 bytes at 0x008E0E50 
[4] Allocated chunk of 0x500 bytes at 0x008E1358 
[5] Allocated chunk of 0x500 bytes at 0x008E1860 
[6] Allocated chunk of 0x500 bytes at 0x008E1D68 
[7] Allocated chunk of 0x500 bytes at 0x008E2270 
[8] Allocated chunk of 0x500 bytes at 0x008E2778 
[9] Allocated chunk of 0x500 bytes at 0x008E2C80 
[10] Allocated chunk of 0x500 bytes at 0x008E3188 
[11] Allocated chunk of 0x500 bytes at 0x008E3690 
[12] Allocated chunk of 0x500 bytes at 0x008E3B98 
[13] Allocated chunk of 0x500 bytes at 0x008E40A0 
[14] Allocated chunk of 0x500 bytes at 0x008E45A8 
[15] Allocated chunk of 0x500 bytes at 0x008E4AB0 
[16] Allocated chunk of 0x500 bytes at 0x008E4FB8 
[17] Allocated chunk of 0x500 bytes at 0x008E54C0 
[18] Allocated chunk of 0x500 bytes at 0x008E7D28 
[19] Allocated chunk of 0x500 bytes at 0x008E5EF8 
[20] Allocated chunk of 0x500 bytes at 0x008E6E10 
Press return to continue
Freed chunk at 0x008E6E10 
Press return to continue
Allocated chunk of 0x500 bytes at 0x008E9148 
Press return to continue

0:003> !heap -x 0x008E6E10     
Entry User Heap Segment Size PrevSize Unused Flags 
----------------------------------------------------------------------------- 
008e6e08 008e6e10 008d0000 008d8d90 508 - 0 LFH;free

  
0:003> !heap -x 0x008E9148 
Entry User Heap Segment Size PrevSize Unused Flags 
----------------------------------------------------------------------------- 
008e9140 008e9148 008d0000 008d8d90 508 - 8 LFH;busy

Perhaps causing a series of allocations of 0x500 byte will allow us to take the freed chunk back.  Press return to cause another 20 allocations of 0x500 bytes and see what happens:

Allocated chunk of 0x500 bytes at 0x008E59F0 
Allocated chunk of 0x500 bytes at 0x008E7318 
Allocated chunk of 0x500 bytes at 0x008E8738 
Allocated chunk of 0x500 bytes at 0x008E6400 
Allocated chunk of 0x500 bytes at 0x008E8C40 
Allocated chunk of 0x500 bytes at 0x008E6908 
Allocated chunk of 0x500 bytes at 0x008E7820 
Allocated chunk of 0x500 bytes at 0x008E8230 
Allocated chunk of 0x500 bytes at 0x008E6E10 
--- got it back --- 
Allocated chunk of 0x500 bytes at 0x008EC740 
Allocated chunk of 0x500 bytes at 0x008EEA78 
Allocated chunk of 0x500 bytes at 0x008EBD30 
Allocated chunk of 0x500 bytes at 0x008EC238 
Allocated chunk of 0x500 bytes at 0x008EDB60 
Allocated chunk of 0x500 bytes at 0x008EF488 
Allocated chunk of 0x500 bytes at 0x008ECC48 
Allocated chunk of 0x500 bytes at 0x008F0DB0 
Allocated chunk of 0x500 bytes at 0x008E99F8 
Allocated chunk of 0x500 bytes at 0x008EEF80 
Allocated chunk of 0x500 bytes at 0x008EB828 
Press return to continue

In this case, it took another 9 allocations to get the freed chunk back.  In fact, if you’d run the same application a couple of times, you’ll see that the number of times it takes to get the freed chunk back, varies largely between 0 (sometimes you’ll get it back LIFO style) and never (at least, not in the first 20 allocations or so)… but in most cases I got it back within the first 10 allocations.  (A lot more structured testing would be needed to find the sweet spot that would provide some sort of predictability. It’ll probably never be 100% reliable, but it may not be too messy either.)

Update (7/7/2016) – I added "LFH_TakeBack" to the github repository, which will automate some statistic gathering.  For each chunksize between 8 and 0x4000, it will enable LFH, alloc a chunk and free it again, and then measure how many allocations are needed to take it back.  The application calculates an average, a minimum and maximum number of tries, and also keeps track how many times the object was not taken back within the first 2000 allocations.

After running the app, it looks like the maximum number of allocations needed sits around 50.

Anyway, looking at the addresses of the allocations, it also looks like the chunks are no longer adjacent (as they were in Windows 7, at least as long as the chunks are inside the same subsegment).

This will certainly make it more complex to create a specific layout/sequence of objects when the LFH is enabled.

LFH_Alloc3

Is LFH still limited to 0x4000 byte chunks (max)?

App:

C:\Users\corelan\Desktop\vc++\win10\LFH_Alloc3\Release>LFH_Alloc3.exe 
Default process heap found at 0x00930000 
Press a key to start...
[1] Allocated chunk of 0x4000 bytes at 0x00940FF8 
[2] Allocated chunk of 0x4000 bytes at 0x00945000 
[3] Allocated chunk of 0x4000 bytes at 0x00949008 
[4] Allocated chunk of 0x4000 bytes at 0x0094D010 
[5] Allocated chunk of 0x4000 bytes at 0x00951018 
[6] Allocated chunk of 0x4000 bytes at 0x00955020 
[7] Allocated chunk of 0x4000 bytes at 0x00959028 
[8] Allocated chunk of 0x4000 bytes at 0x0095D030 
[9] Allocated chunk of 0x4000 bytes at 0x00961038 
[10] Allocated chunk of 0x4000 bytes at 0x00965040 
[11] Allocated chunk of 0x4000 bytes at 0x00969048 
[12] Allocated chunk of 0x4000 bytes at 0x0096D050 
[13] Allocated chunk of 0x4000 bytes at 0x00971058 
[14] Allocated chunk of 0x4000 bytes at 0x00975060 
[15] Allocated chunk of 0x4000 bytes at 0x00979068 
[16] Allocated chunk of 0x4000 bytes at 0x0097D070 
[17] Allocated chunk of 0x4000 bytes at 0x00981078 
[18] Allocated chunk of 0x4000 bytes at 0x0098D0B8 
[19] Allocated chunk of 0x4000 bytes at 0x009950C8 
[20] Allocated chunk of 0x4000 bytes at 0x009910C0 
Press return to continue
[1] Allocated chunk of 0x4008 bytes at 0x009C7008 
[2] Allocated chunk of 0x4008 bytes at 0x009CB018 
[3] Allocated chunk of 0x4008 bytes at 0x009CF028 
[4] Allocated chunk of 0x4008 bytes at 0x009D3038 
[5] Allocated chunk of 0x4008 bytes at 0x009D7048 
[6] Allocated chunk of 0x4008 bytes at 0x009DB058 
[7] Allocated chunk of 0x4008 bytes at 0x009DF068 
[8] Allocated chunk of 0x4008 bytes at 0x009E3078 
[9] Allocated chunk of 0x4008 bytes at 0x009E7088 
[10] Allocated chunk of 0x4008 bytes at 0x009EB098 
[11] Allocated chunk of 0x4008 bytes at 0x009EF0A8 
[12] Allocated chunk of 0x4008 bytes at 0x009F30B8 
[13] Allocated chunk of 0x4008 bytes at 0x009F70C8 
[14] Allocated chunk of 0x4008 bytes at 0x009FB0D8 
[15] Allocated chunk of 0x4008 bytes at 0x009FF0E8 
[16] Allocated chunk of 0x4008 bytes at 0x00A030F8 
[17] Allocated chunk of 0x4008 bytes at 0x00A07108 
[18] Allocated chunk of 0x4008 bytes at 0x00A0B118 
[19] Allocated chunk of 0x4008 bytes at 0x00A0F128 
[20] Allocated chunk of 0x4008 bytes at 0x00A13138 
Press return to continue

WinDBG: 0x4000 bytes

0:001> !heap -x 0x00981078 
Entry User Heap Segment Size PrevSize Unused Flags 
----------------------------------------------------------------------------- 
00981070 00981078 00930000 00930000 4008 4008 8 busy
0:001> !heap -x 0x0098D0B8 
Entry User Heap Segment Size PrevSize Unused Flags 
----------------------------------------------------------------------------- 
0098d0b0 0098d0b8 00930000 00938c48 4008 - 8 LFH;busy

WinDBG: 0x4008 bytes

0:001> !heap -x 0x00A07108 
Entry User Heap Segment Size PrevSize Unused Flags 
----------------------------------------------------------------------------- 
00a07100 00a07108 00930000 00930000 4010 4010 8 busy

0:001> !heap -x 0x00A0B118 
Entry User Heap Segment Size PrevSize Unused Flags 
----------------------------------------------------------------------------- 
00a0b110 00a0b118 00930000 00930000 4010 4010 8 busy

Answer:  YES, 0x4000 seems to be the maximum size (just like on Windows 7)

LFH_TakeBack2

The LFH_Alloc* exercises demonstrate that chunks are no longer allocated in an consecutive manner inside a LFH subsegment. Of course, this complicates creating a specific layout within the subsegment.   I still wanted to know if it would be possible to replace the memory space used by a LFH chunk by an LFH allocation of a size from a different bucket. As an example, can I take the space of a 0x58 byte chunk using a 0x88 byte allocation, within the LFH.

As the LFH subsegments are used to keep chunks of the same bucket size together, this would require clearing out the entire subsegment used for storing the vulnerable object, and hopefully the Heap Manager will reuse those pages for another subsegment (allocations for a different bucket size).

LFH_TakeBack2 demonstrates if it works or not.   The idea is to try to place the "vulnerable" object in a subsegment where you control all the other chunks.  As soon as the vulnerable object gets freed, you cause all the other chunks to be freed as well.  Hopefully, this will also release the entire subsegment and its pages, so they can be reused again (even for a subsegment associated with chunksizes that fall in a different bucket).

App:

C:\Users\corelan\Desktop\vc++\win10_heap\LFH_TakeBack2\Release>LFH_TakeBack2.exe
  
Vulnerable object of 0x00000058 bytes at 0x01136B98, filled with 'A'

Allocations done. Press return to start free process

WinDBG:

0:003> dd 0x01136B98
01136b98  41414141 41414141 41414141 41414141
01136ba8  41414141 41414141 41414141 41414141
01136bb8  41414141 41414141 41414141 41414141
01136bc8  41414141 41414141 41414141 41414141
01136bd8  41414141 41414141 41414141 41414141
01136be8  41414141 41414141 07fe9621 88011d00
01136bf8  00000000 00000000 00000000 00000000
01136c08  00000000 00000000 00000000 00000000

  
0:003> !heap -p -a 0x01136B98
    address 01136b98 found in
    _HEAP @ e30000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        01136b90 000c 0000  [00]   01136b98    00058 - (busy)
  
0:003> !heap -x 0x01136B98
Entry     User      Heap      Segment       Size  PrevSize  Unused    Flags
-----------------------------------------------------------------------------
01136b90  01136b98  00e30000  00e45638        60      -            8  LFH;busy

Continue with App:

Vulnerable object at 0x01136B98 was freed
Free done. Press return to start new allocations (size 0x00000088)
Allocations done.   Check if 0x01136B98 contains 'B' now

WinDBG:

0:001> dd 0x01136B98
01136b98  42424242 42424242 42424242 42424242
01136ba8  42424242 42424242 42424242 42424242
01136bb8  42424242 42424242 42424242 42424242  
01136bc8  42424242 42424242 42424242 42424242
01136bd8  42424242 42424242 42424242 42424242
01136be8  42424242 42424242 42424242 42424242
01136bf8  42424242 42424242 42424242 42424242
01136c08  42424242 42424242 07f296dd 8800bf00

  
0:001> !heap -x 0x01136B98
Entry     User      Heap      Segment       Size  PrevSize  Unused    Flags
-----------------------------------------------------------------------------
01136b80  01136b88  00e30000  00e38ca0        90      -            8  LFH;busy 

Size is now 0x90.   So, the mechanism still works (just like in older Windows versions). Of course, because the sequence of chunks inside a segment is not fully under our control, it will be difficult to control specific bytes of the freed object when you replace it with a different sized chunk.  

Large chunks

Large_Alloc1

What do virtualallocdblock chunks/allocations look like under WIndows 10?

In order to create such chunks, we need to cause HeapAlloc/RtlAllocateHeap allocations of a size that is larger than the VirtualMemoryThreshold value in the heap header.  In the example application, I am triggering 20 allocations of 0x7ffb0 bytes (which is larger than the 7ff00 byte threshold).

App:

C:\Users\corelan\Desktop\vc++\win10\Large_Alloc1\Release>Large_Alloc1.exe 
Default process heap found at 0x00E20000 
Press a key to start...
[1] Allocated chunk of 0x7ffb0 bytes at 0x00C48020 
[2] Allocated chunk of 0x7ffb0 bytes at 0x01110020 
[3] Allocated chunk of 0x7ffb0 bytes at 0x011A1020 
[4] Allocated chunk of 0x7ffb0 bytes at 0x0123F020 
[5] Allocated chunk of 0x7ffb0 bytes at 0x01326020 
[6] Allocated chunk of 0x7ffb0 bytes at 0x013BA020 
[7] Allocated chunk of 0x7ffb0 bytes at 0x0144C020 
[8] Allocated chunk of 0x7ffb0 bytes at 0x014D2020 
[9] Allocated chunk of 0x7ffb0 bytes at 0x0156D020 
[10] Allocated chunk of 0x7ffb0 bytes at 0x015F4020 
[11] Allocated chunk of 0x7ffb0 bytes at 0x01680020 
[12] Allocated chunk of 0x7ffb0 bytes at 0x01712020 
[13] Allocated chunk of 0x7ffb0 bytes at 0x017AB020 
[14] Allocated chunk of 0x7ffb0 bytes at 0x0183B020 
[15] Allocated chunk of 0x7ffb0 bytes at 0x018C9020 
[16] Allocated chunk of 0x7ffb0 bytes at 0x01957020 
[17] Allocated chunk of 0x7ffb0 bytes at 0x019EA020 
[18] Allocated chunk of 0x7ffb0 bytes at 0x01A75020 
[19] Allocated chunk of 0x7ffb0 bytes at 0x01B09020 
[20] Allocated chunk of 0x7ffb0 bytes at 0x01B9D020 
Press return to continue

WinDBG: (output of !heap -p -h

, limited to information related with VirtualAllocdBlocks)

VirtualAllocdBlocks @ e2009c 
00c48018 10000 0004 [00] 00c48020 7ffb0 - (busy VirtualAlloc) 
01110018 10000 0000 [00] 01110020 7ffb0 - (busy VirtualAlloc) 
011a1018 10000 0000 [00] 011a1020 7ffb0 - (busy VirtualAlloc) 
0123f018 10000 0000 [00] 0123f020 7ffb0 - (busy VirtualAlloc) 
01326018 10000 0000 [00] 01326020 7ffb0 - (busy VirtualAlloc) 
013ba018 10000 0000 [00] 013ba020 7ffb0 - (busy VirtualAlloc) 
0144c018 10000 0000 [00] 0144c020 7ffb0 - (busy VirtualAlloc) 
014d2018 10000 0000 [00] 014d2020 7ffb0 - (busy VirtualAlloc) 
0156d018 10000 0000 [00] 0156d020 7ffb0 - (busy VirtualAlloc) 
015f4018 10000 0000 [00] 015f4020 7ffb0 - (busy VirtualAlloc) 
01680018 10000 0000 [00] 01680020 7ffb0 - (busy VirtualAlloc) 
01712018 10000 0000 [00] 01712020 7ffb0 - (busy VirtualAlloc) 
017ab018 10000 0000 [00] 017ab020 7ffb0 - (busy VirtualAlloc) 
0183b018 10000 0000 [00] 0183b020 7ffb0 - (busy VirtualAlloc) 
018c9018 10000 0000 [00] 018c9020 7ffb0 - (busy VirtualAlloc) 
01957018 10000 0000 [00] 01957020 7ffb0 - (busy VirtualAlloc) 
019ea018 10000 0000 [00] 019ea020 7ffb0 - (busy VirtualAlloc) 
01a75018 10000 0000 [00] 01a75020 7ffb0 - (busy VirtualAlloc) 
01b09018 10000 0000 [00] 01b09020 7ffb0 - (busy VirtualAlloc) 
01b9d018 10000 0000 [00] 01b9d020 7ffb0 - (busy VirtualAlloc)

Yes, we can still trigger this kind of allocations.  Due to the nature of this type of allocations they are still placed at the start of a fresh new page (which is why we’re seeing the start address alignments).  On the other hand, the gaps between 2 allocations seems to be larger than under Windows 7. 

This means that it will become harder to use this type of allocations to fill up a larger memory region as part of a heap spray.  There will be much bigger holes in between allocations, and the locations of the holes are also non-predictable, which means we may not be able to rely on absolute heap spray addresses as much as we could in Windows 7.

Perhaps a larger series of allocations is needed, and a larger number of runs, to find "sweet spots", addresses that are allocated more often than others.  Not sure what kind of percentage of predictability we may be able to obtain, but it might be worth the try.

Large_Alloc2

So… can we do a precise heap spray under Windows 10?

Well…. yes.  The key is to avoid LFH, and to avoid virtualallocdblocks as well.

Use a "sweet" size and a "sweet" number of allocs to get aligned consecutive allocations (starting at ????0048) as a normal chunk, inside a normal segment.  Perhaps the first few allocations won’t start at that aligned address (because there are already some smaller allocations in the segment), but as soon as the allocations trigger the creation of another segment, and you manage to take the first spot, your allocations should be aligned.

App:

C:\Users\corelan\Desktop\vc++\win10\Large_Alloc2\Release>Large_Alloc2.exe 
Default process heap found at 0x012B0000 
Press a key to start...
[1] Allocated chunk at 0x012C0FF8 
[2] Allocated chunk at 0x01300FF8 
[3] Allocated chunk at 0x01340FF8 
[4] Allocated chunk at 0x015B0048 
[5] Allocated chunk at 0x015F0048 
[6] Allocated chunk at 0x01630048 
[7] Allocated chunk at 0x016B0048 
[8] Allocated chunk at 0x016F0048 
[9] Allocated chunk at 0x01730048 
[10] Allocated chunk at 0x01770048 
[11] Allocated chunk at 0x017B0048 
[12] Allocated chunk at 0x017F0048 
[13] Allocated chunk at 0x01830048 
[14] Allocated chunk at 0x018B0048 
[15] Allocated chunk at 0x018F0048 
[16] Allocated chunk at 0x01930048 
[17] Allocated chunk at 0x01970048 
[18] Allocated chunk at 0x019B0048 
[19] Allocated chunk at 0x019F0048 
[20] Allocated chunk at 0x01A30048 
[21] Allocated chunk at 0x01A70048 
[22] Allocated chunk at 0x01AB0048
...

WinDBG:

0:003> d 0c0c0c0c 
0c0c0c0c 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 
0c0c0c1c 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 
0c0c0c2c 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 
0c0c0c3c 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 
0c0c0c4c 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 
0c0c0c5c 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 
0c0c0c6c 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 
0c0c0c7c 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA

To turn this into a precise heap spray, we need to overcome the fact that we don’t know the exact start address of the first one.  As we know that the start addresses will be aligned eventually to the start of a page, and we can control the size of the allocations, we simply have to repeat the same structure  (junk + ROP + shellcode + junk) every 0x1000 bytes inside each allocation (as explained in the heap spray tutorials on this site). This should allow you to put/find your content at a predictable address.  The same logic applies if you need to put specific values at specific places… simply repeat the layout every 0x1000 bytes and you should be fine.

In "Precise_Spray", the goal is to put marker "$$$$" (\x24\x24\x24\x24) at  0x0c0c0c0c:

C:\Users\corelan\Desktop\vc++\win10_heap\Precise_Spray\Release>Precise_Spray.exe
Default process heap found at 0x00550000
Press a key to start...
Spray done, check 0x0c0c0c0c
>> Contents at 0x0c0c0c0c: 24242424

0:003> db 0c0c0c0c

0c0c0c0c  24 24 24 24 20 20 20 20-20 20 20 20 20 20 20 20  $$$$            
0c0c0c1c  20 20 20 20 20 20 20 20-20 20 20 20 20 20 20 20                  
0c0c0c2c  20 20 20 20 20 20 20 20-20 20 20 20 20 20 20 20                  
0c0c0c3c  20 20 20 20 20 20 20 20-20 20 20 20 20 20 20 20                  
0c0c0c4c  20 20 20 20 20 20 20 20-20 20 20 20 20 20 20 20                  
0c0c0c5c  20 20 20 20 20 20 20 20-20 20 20 20 20 20 20 20                  
0c0c0c6c  20 20 20 20 20 20 20 20-20 20 20 20 20 20 20 20                  
0c0c0c7c  20 20 20 20 20 20 20 20-20 20 20 20 20 20 20 20                  

Of course, in a complex/multithreaded application, there will be ‘noise’ (other allocations and frees) at the same time your heapspray is running, and which could affect the placement of your allocations within the segment.    A possible approach could be to cause some large allocations first (50 allocations of 0x1ff00 bytes or so… any big size, smaller than the chunk size you’re using for the actual spray), each time followed by a small allocation (which we will keep allocated, to avoid that the big ones get coalesced),  and then free the large ones.  That way, the application can use those freed chunks, split them, consume them, without bothering your aligned spray at all. 

I’ve had good results with spraying using chunk sizes of 0x20000-8 bytes, and 0x40000-8 bytes, but I guess any similar aligned size that is a multiple of a page size will work.

Good luck y’all.  <3

Peter

---

Oh yeah, before I forget, please check out:

https://facebook.com/demandglobalchange // https://bit.ly/demandglobalchange_full // https://bit.ly/demandglobalchange

Read & share. Give people reasons to live, not to die for.  thank you.

---

© 2016 – 2021, Peter Van Eeckhoutte (corelanc0d3r). All rights reserved.

Similar/Related posts:

BlackHatEU2013 – Day2 – Advanced Heap Manipulation in Windows 8 Analyzing heap objects with mona.py Heap Layout Visualization with mona.py and WinDBG HITB2012AMS Day 2 – Ghost in the Allocator DEPS – Precise Heap Spray on Firefox and IE10