Heap Exploitation from First Principles

Kevin Massey explains why someone might write a userland heap allocator from scratch. A stripped-down version makes the mechanics of production allocators easier to follow, and it supports vulnerability research because custom allocators tend to repeat the bug classes of well-known ones. He illustrates the point with a glibc flaw documented in 2001, believed fixed the following year, and not found again until 2018.

He walks through a simple allocator with inline headers holding a size, a next pointer, a free flag and a magic value, covering allocation, freeing and chunk reuse. A heap overflow that rewrites a neighbouring header's next pointer makes a later allocation return a stack address, which lets him overwrite a function pointer in a jump table so the program calls a different function. He then extends the design with fast bins, which behave as last-in-first-out stacks for small fixed sizes, plus sorted doubly linked bins for larger chunks, along with 8-byte alignment, an arena and a top chunk.

The final section covers a use-after-free against fast bins, where an overwritten forward pointer makes a later allocation return an attacker-chosen target. Massey notes that heap exploits can also corrupt data or global offset table entries, and that a clean exploit keeps the process running so it goes unnoticed. His main takeaway is that knowing an allocator's intended invariants is the fastest route to finding its flaws.