Nozzle: Protecting Browsers Against Heap Spraying Attacks

A slightly more technical entry today, to prove that it's not all net-centric cyberwar theorising or online gaming here at Meme Overload (Or "Meme Over" as I've started thinking of it, as in "That's it man, meme over man, meme over!")

Nozzle: Protecting Browsers Against Heap Spraying Attacks is a project from Microsoft Research that proposes a technique for detecting heap spraying attacks. If you need a heap spraying refresher or aren't quite sure what I'm on about yet have a look at the following wikipedia entries: Heap Spraying, Buffer Overflow (there's even a reference to the Nozzle paper on the heap spraying page!). Basically heap spraying is a technique that makes heap buffer overflows reliably exploitable by increasing your chances of having your overwritten pointer point at injected code. In practice heap spraying is generally some injected javascript that loops around allocating strings filled with your shellcode.

Nozzle proposes to detect attempted heap spraying attacks by watching a process' allocated heap blocks and trying to determine which blocks contain executable code (basically by trying to disassemble them). Nozzle keeps some statistics about the proportion of the heap that has shellcode-like data in it and will alert if that number gets too high.

From Zorn, Livshits and Ratanaworabhan's experiments applying the technique to Firefox it seems to have worked really well. My understanding is that they modified Firefox with binary detour patches to add worker threads that checks the memory regions and modified the memory allocation routines to queue up newly allocated blocks for scanning. There's a slight timing problem here as at the time of allocation the memory block will not contain real data yet and so that a premature scan might yield false negatives but since new memory is added to the end of the work queue the memory will almost always have matured before being scanned. Only memory allocations of 32 bytes are examined because 32 bytes is really too small for any significant payload, especially when a NOP sled is taken into account and to minimize overhead only a random subset of blocks are scanned.

It's a very impressive piece of work. I'm not sure why they chose detour patches when they had the source code of Firefox to modify to prove their concept or if they were going for compatibility with closed source software why they didn't use IAT hooks via an injected DLL but still I'm a big fan of this work. I'd love to see Microsoft Research release some code for this so that we mere mortals can have a play. I'm also going to keep an eye on things in the hope that a more general solution is implemented.