Double Free Vulnerabilities - Part 1

[Symantec]

Double Free Vulnerabilities - Part 1
<p>In light of the recent CSRSS double free bug, I wanted to provide some information on the exploitation of double frees on Windows on XP SP2 and later. Prior to XP SP2, double frees were trivial to exploit, but now the security cookie (in each heap chunk) and safe unlinking checks make it more difficult to exploit. So this blog entry will discuss the exploitability on XP SP2 and later heap implements.</p>

<p>Note: If you're not familiar with Windows heap terminology, please review the slides from our CanSecWest 2004 heap presentation, archived here: <a href="http://www.cybertech.net/~sh0ksh0k/projects/winheap">http://www.cybertech.net/~sh0ksh0k/projects/winheap</a>.</p>

<p>Oded Horovitz and I did not look into this topic much in our original presentation on Reliable Windows Heap Exploitation at CanSecWest 2004. Later that same year, I discussed how to defeat the safe unlinking check at SyScan 2004, but I did not consider its relevance to double free vulnerabilities. In other words, the techniques I’ll describe here are not new, but I have not seen their application to exploiting double frees on XP SP2 and later publicly documented anywhere.</p>

<p><strong>About double free vulnerabilities</strong></p>

<p>A double free vulnerability is where a pointer is accidentally freed twice. The idea is generally that the chunk is freed (and added to a <span class="MD_monospace">FreeList</span> for future use). It is later allocated and used by a different allocation before being freed again (erroneously). This gives an attacker the ability to arbitrarily set the forward/backward links in the heap chunk. A free chunk is added to a doubly linked list of other chunks on the same free list. These forward and backward pointers are stored within the chunk data itself (offset 0 and 4 of the chunk data). In the case of double free vulnerabilities, this means the attacker has full control over the <span class="MD_monospace">FreeList.Flink</span> and <span class="MD_monospace">FreeList.Blink</span> in the double freed chunk, making 4-byte overwrites trivial.</p>

<p> On XPSP2, however, it is no longer so trivial because the safe unlink check ensures before unlinking that:<br />
<span class="MD_monospace">Chunk->FreeList.Blink->Flink == &Chunk <br />
&& <br />
Chunk->FreeList.Flink->Blink == &Chunk</span> </p>

<p><strong>Review of technique to defeat safe unlinking</strong></p>

<p>I demonstrated in the SyScan presentation that this could be evaded when the chunk is freed to a <span class="MD_monospace">FreeList</span> and it is the only entry on the <span class="MD_monospace">FreeList</span>. Let's review how safe unlinking can be defeated before we move on to double-free vulnerabilities. <br />
<br />
How is it possible to defeat the safe unlink check? Because then the <span class="MD_monospace">FreeList</span> list head, which is a circular linked list, looks like this:<br />
<span class="MD_monospace">FreeList[SizeX].Flink = &YourChunk<br />
FreeList[SizeX].Blink = &YourChunk<br />
YourChunk.Blink = &FreeList[SizeX]<br />
YourChunk.Flink = &FreeList[SizeX]</span><br />
<br />
That condition is only true if the chunk is the only item on the <span class="MD_monospace">FreeList</span> for <em>SizeX</em> (that is, <span class="MD_monospace">Chunk.Size</span> is equal to <em>SizeX</em>), since Chunk is both the first and last entry (again, the list is circular). This allows us to defeat the safe unlink check by flipping the <span class="MD_monospace">Flink/Blink</span>. Now if you know that <span class="MD_monospace">Flink</span> is at offset 0 and <span class="MD_monospace">Blink</span> is at offset 4 of the LIST_ENTRY structure, you can defeat the safe unlink checking using this setup:<br />
Set malicious Flink to &FreeList[SizeX]-4 (in other words &FreeList[SizeX-1].Blink)<br />
Set malicious Blink to &FreeList[SizeX]+4 (in other words &FreeList[SizeX].Blink) </p>

<p>This works because:<br />
YourChunk.Blink->Flink == *(*YourChunk.Blink)+0) == *(&FreeList[SizeX].Blink)<br />
YourChunk.Flink->Blink == *(*YourChunk.Flink)+4) == *(&FreeList[SizeX].Flink) <br />
<br />
Both of these point to YourChunk so the safe unlink check is defeated, but the unlink result will corrupt the heap. The second unlink will return a pointer directly into FreeLists[] (meaning your can arbitrarily corrupt the FreeLists following the second unlink). </p>

<p>Original flink/blink in overflowed heap chunk:<br />
<span class="MD_monospace">freelist[n-1] [0x003401b8] Flink 0x003401b8 Blink 0x003401b8<br />
freelist[n] [0x003401c0] Flink 0x00341fb0 Blink 0x00341fb0<br />
chunk [0x00341fa8] Flink 0x003401c0 Blink 0x003401c0</span> </p>

<p>After modifying the flink/blink in the overflowed heap chunk:<br />
<span class="MD_monospace">freelist[n-1] same<br />
freelist[n] same<br />
chunk [0x00341fa8] Flink 0x003401bc Blink 0x003401c4</span></p>

<p>After 1st allocation following the modification (returned 0x00341fb0):<br />
<span class="MD_monospace">freelist[n-1] same <br />
freelist[n] [0x003401c0] Flink 0x003401c4 Blink 0x003401bc</span></p>

<p>After 2nd allocation following the modification (returned 0x003401bc):<br />
<span class="MD_monospace">freelist[n-1] [0x003401b8] Flink 0x0008015c Blink 0x003401b8<br />
freelist[n] [0x003401c0] Flink 0x003401c4 Blink 0x003401bc</span> </p>

<p>After copying 0x909090909090909090 into chunk returned from the 2nd allocation:<br />
<span class="MD_monospace">freelist[n-1] [0x003401b8] Flink 0x0008015c Blink 0x90909090<br />
freelist[n] [0x003401c0] Flink 0x90909090 Blink 0x90909090</span> <br />
<br />
So in this case, by switching the <span class="MD_monospace">Flink/Blink</span> we corrupted the heap and actually managed to get a pointer returned to the <span class="MD_monospace">FreeLists[]</span> itself, which means we can now arbitrarily modify future allocations by setting the <span class="MD_monospace">FreeLists</span> list heads to what we want. </p>

<p>To be continued in Part 2…<br />
</p>
http://www.symantec.com/enterprise/security_response/weblog/2007/01/double_free_vulnerabilities_pa.html
http://www.symantec.com/enterprise/security_response/weblog/2007/01/double_free_vulnerabilities_pa.html
Fri, 19 Jan 2007 05:45:00 -0800