Internet Security Systems - AlertCon(TM)

Required Reading for our Blackhat Talk

Posted by John McDonald on July 28, 2009 at 8:15 AM EDT.

Analyzing subtle heap corruption vulnerabilities on Windows XP/2003 is not something that one would typically describe as "a pleasant experience," or "fun." Throw in decommitting behavior and lots of activity with large heap blocks, and your description might lean more towards "baffling," and "I want to die."

This is where I, your humble X-Force researcher, found myself in the not too distant past. After googling "suicidal ideation," wondering what is wrong with Finland, and then hiding under my desk, I decided to pull myself together and do what everyone else in my situation would do:

I asked Mark Dowd.

Unfortunately, he didn't have much advice to lend, as they apparently don't really use Windows XP a lot where he's from on account of some sort of "machine uprising." (Ed. note: Mark is from the future.) Resigned to my fate, I returned to my desk, fired up IDA, and eventually came up with this paper. In short, here's what I cover:

Large blocks under the Windows XP backend Heap Manager have a tendency to be de-committed when they are freed. This means that the memory backing them is unmapped, so attempts to access the location where the block used to live will result in an access violation. This can be a considerable roadblock when analyzing potential vulnerabilities involving corruption of large blocks or stale pointers. (Note that by large blocks, I mean blocks larger than 1023 bytes, but smaller than the virtual allocation threshold.)

The decommitting policy for free heap memory can be changed by runtime heuristics, and these changes occur in concert with the instantiation of an additional mechanism: the heap cache. This paper discusses intentionally invoking the heap cache in order to change the decommitting policy, and also documents several techniques for attacking the heap cache data structure once it is present. Many of these techniques can work to make one or two byte overflows of large block heap meta-data exploitable.

I made an effort to give lots of pointers to existing heap research, and discuss how other attacks compare and contrast with the techniques highlighted in this paper. The content is a good prerequisite for our Blackhat Talk & Paper, which are coming out tomorrow. Enjoy!

Comments or opinions expressed on this Weblog are the opinions of the authors alone. They are not necessarily reviewed in advance by anyone but the individual authors, and neither IBM Internet Security Systems nor any other party necessarily agrees with them. The views expressed by outside contributors and links to outside websites do not represent the views of IBM Internet Security Systems, its management or employees. All content on this Weblog has been made available on an “as-is” basis, and IBM Internet Security Systems shall not be liable for any direct or indirect damages arising out of use of this Weblog.