D^3CTF 2019 new_heap — high-level notes

CTF challenge from D^3CTF 2019: a small heap menu (alloc / free / exit) with a limited number of slots and capped chunk sizes.

Challenge theme

• Classic “custom allocator front-end” pwnable
• Source analysis theme: free path clears ownership poorly, enabling double-free-class misuse
• Later discussion in the original post centers on glibc I/O structures and heap metadata—kept here only as topic labels, not procedures

Vulnerability class / root cause

• Use-after-free / double-free: the free routine does not null the stored heap pointer after release, so the same index can be freed again and the dangling pointer remains usable for later allocs.
• Secondary theme in the writeup: abusing corrupted allocator metadata and process I/O state—still the same memory-safety class (unsafe reuse of freed objects).

Impact (abstract)

Double-free and dangling pointers in allocators commonly escalate to arbitrary read/write and then code execution in unconstrained processes. In a CTF that means shell/flag; in real software it is RCE if the allocator is reachable with attacker-controlled free/alloc patterns.

Mitigations / lessons

• Always clear or tombstone pointers after free; refuse double-free in debug builds.
• Prefer hardened allocators / sanitized builds in testing; consider safe languages for new services.
• Do not rely on “no print of chunk contents” as security—absence of a leak helper is not a fix for UAF.

Solve steps and PoC omitted.