« MS cuts off patches to unauthorized Windows copies | Main | The NYT on Alexander Shulgin »
January 30, 2005
Defeating Windows XP SP2 buffer overflow protection
Windows XP SP2 is built with some memory protection features to prevent the exploitation of buffer overflows. Definitely a good idea, but unfortunately, they're not perfect and the guys at Maxpatrol have figured out how to bypass them them:And the second weak spot the manipulation of the lookaside lists doesn`t assume any header sanity checking, there isn`t even a simple cookie check there. Which, theoretically, results in possibility to overwrite up to 1016 bytes in an arbitrary memory location.The exploitation scenario could proceed as follows:
if, during the overflow the concidental memory block is free and is residing in the lookaside list, then it becomes possible to replace the Flink pointer with an arbitrary value.
Then, if the memory allocation of this block happens, the replaced Flink pointer will be copied into the header of the lookaside list and during the next allocation HeapAlloc() will return this fake pointer.The prerequisite for successful exploitation is existence of a free block in lookaside list which neighbors with the buffer we overflow.
I'm not an expert on this kind of memory exploit, but it looks to me like this is a simple implementation error on Microsoft's part. It should be relatively straightforward for them to fix, and since it's clear that they're trying to do the right thing, I'd expect them to fix it in some future SP.
The interesting question is what the working envelope of the bypass is. Does it totally defeat SP2's heap protection or are there a substantial number of vulnerabilities which can't be exploited this way? As I read this disclosure, the bug requires that the overflowable buffer be next to some block on the lookaside list, which requires a very specific allocation and freeing order. This suggests that only some fraction of programs will be vulnerable to this bypass technique.
Posted by ekr at January 30, 2005 8:59 AM | Filed under: