Understand Heap Exploitation Concepts

Topic Overview

Heap Exploitation Concepts

Heap exploitation targets dynamic memory management bugs rather than stack overflows. Corrupting heap metadata via malloc/free bugs can lead to arbitrary memory writes and code execution.

Heap Chunk Structure and Vulnerabilities

A glibc heap chunk contains:

• size: chunk size including metadata (low 3 bits are flags)
• fd / bk: forward/backward pointers in free lists
• User data starts after the metadata header

Key vulnerability classes:

• Use-after-free: dangling pointer points to reallocated attacker-controlled data
• Double-free: freeing the same chunk twice corrupts free list linking
• Heap overflow: writing past a buffer overwrites the next chunk's metadata

For example, a double-free of chunk A can cause malloc to return the same address twice, giving two pointers to one allocation.

For This Exercise

You will simulate a tcache-style allocator over a malloc/free trace: compute the real chunk-size rounding (align16(req + 8), minimum 32 on x64), service allocations LIFO out of the per-size free bucket exactly like tcache, detect double frees the way glibc's tcache key check does, and report the final heap state. The same reuse pattern is what turns a use-after-free into attacker-controlled data.

Modern Heap Defenses

Glibc's safe unlinking checks that fd->bk == chunk before removing a free chunk from a doubly linked list. Tcache (per-thread cache) added in glibc 2.26 speeds allocation but introduced new double-free checks. Safe-linking XOR-mangles pointers in recent versions. Despite defenses, heap bugs remain the top vulnerability class in browsers, where attackers combine UAF with JavaScript type confusion for reliable exploitation.

Write a C program that processes a malloc/free trace and reports allocator behavior.

Requirements:

• Read an operation count, then operations: A <name> <req> allocates and F <name> frees
• Compute the chunk size like glibc does: align16(req + 8), minimum 32 bytes on x64
• Track one LIFO free bucket per chunk size: free pushes, malloc pops the most recently freed chunk of the same size class and REUSES its address (this is the use-after-free primitive)
• A second free of a chunk already sitting in its bucket is a DOUBLE FREE DETECTED, exactly what glibc's tcache key check aborts on
• End with a heap summary: committed bytes, live chunks, tcache entries

Success Criteria:

• Chunk sizes are computed from the request, not hardcoded (req=1 and req=24 both give 32; req=25 gives 48)
• Reuse returns the most recently freed chunk of the matching size class
• Double-free detection fires before the trace continues