Double Free Vulnerabilities - Part 2

Symantec · #1 02-08-2007, 12:27 AM

Double Free Vulnerabilities - Part 2
Continued from <a href="http://www.symantec.com/enterprise/security_response/weblog/2007/01/double_free_vulnerabilities_pa.html">Part 1</a>... 

Exploiting double free vulnerabilities: Case 1

The first way that a double free vulnerability can be exploited is when the first free puts the chunk on the Lookaside (which the Windows heap implementation tries to use before the FreeList since it's more efficient). When a chunk is freed to the Lookaside, the Chunk is still marked as busy (that is, Chunk.Flags & BUSY_FLAG is set) to prevent the chunk from being coalesced with the previous/next chunk. That's because entries on the Lookaside list are meant to be a fast allocate/deallocate (akin to "fast bins" in the GLIBC and related Unix heap implementations). By contrast, entries on the FreeList are frequently coalesced when a chunk is being freed and the chunk before/after it is also free (to make larger contiguous chunks of memory available and avoid heap fragmentation).

So after the first free (in the double free vulnerability) the chunk is put onto the Lookaside and left marked as busy. The Lookaside will only fit four entries per chunk size (initially)â€”in other words, only allow four chunks of size X before putting the remainder on the FreeList. If an attacker can manipulate how many allocations/frees occur (as is possible with some vulnerabilities, such as the Exchange XEXCH heap vulnerability from a year or two ago), the attacker can cause the first free to fill up the Lookaside. The second free (the double free that produces the vulnerability), therefore, will also put the chunk onto the FreeLists. That is, there are two different locationsâ€”the Lookaside[SizeX] and also the FreeLists[SizeX]â€”that point to this chunk. That means we can allocate the chunk off the Lookaside first (since the Lookaside is checked first) and then overwrite the Flink/Blink still contained in the chunk's data (since it's still on the FreeList). So when the SizeX chunk on the FreeLists is eventually allocated, it will unlink that chunk (which is simultaneously allocated via the Lookaside) and a four-byte overwrite will occur since the attacker has already modified that chunk.

Exploiting double free vulnerabilities: Case 2

Another interesting case of double frees is when both times the chunk is put on the Lookaside list (that is, there are at least two available slots on Lookaside[SizeX]). Since the entry is still marked as busy after the first free (since chunks on the Lookaside are left as busy) it will be freed again, and the same chunk will be on the Lookaside twice: 
 
Lookaside[SizeX] -> AttackerChunk -> AttackerChunk

This means that after the first allocation, AttackerChunk will be returned (the first entry) but Lookaside[SizeX] will still point to AttackerChunk. Because AttackerChunk has already been allocated once, the attacker can modify the Flink pointer (offset 0 of a free chunk on the Lookaside) and then allocate a SizeX chunk again. The Lookaside will now point to arbitrary address. With one final allocation of SizeX, the attacker will receive a pointer to whatever address he overwrites the Flink with and will be able to modify up to SizeX bytes at an arbitrary address in memory.

Windows Vista heap mitigations

Heap overflows on Windows Vista have several mitigations that will make double free vulnerabilities more difficult to exploit: 

1. Randomized heap base. You need to know the FreeLists[] address in order to defeat safe unlinking. 
2. The Flink/Blink are now encoded pointers (they are XORâ€™d with a random value initialized once when the process starts). So even if you know the FreeLists[] address, you also have to know the random value that the Flink/Blink are XORâ€™d with. If you guess the incorrect random value, you will read from random memory locations. 
3. Exit on heap corruption rather than silently ignored. This is opt-in functionality, as far as I know, but most of the Windows core components (I assume CSRSS also) will have this enabled. 
4. The Lookaside list has been replaced with the Low Fragmentation Heap (LFH). Iâ€™ve briefly touched on the LFH implementation in the SyScan 2004 presentation. It has not been well ****yzed yet, but initial indications are that LFH is significantly harder to abuse than the Lookaside list was. 

http://www.symantec.com/enterprise/security_response/weblog/2007/01/double_free_vulnerabilities_pa_1.html
http://www.symantec.com/enterprise/security_response/weblog/2007/01/double_free_vulnerabilities_pa_1.html
Mon, 22 Jan 2007 06:30:00 -0800

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)