Heap Memory Management

The way GLIBC manages dynamically allocated memory matters when developing an exploit for a heap-based overflow. This also depends on which version of GLIBC is used, as different versions have various mitigations in place for preventing heap-based attacks.

The general idea of how memory is managed remains the same: When a process requests some memory through an interface like malloc, the allocator will allocate this memory, known as a chunk along with a 16 (0x10) byte header containing metadata. When the memory is no longer needed and deallocated using free(), libc will store the chunk's address into an internal list of free memory blocks for later re-use. There are five types of lists, known as bins:

• 62 small bins for chunks less than 1024 bytes.
• 63 large bins for chunks greater than 1024 bytes.
• Unsorted bin used as a temporary cache for chunks that don't fit into the tchache or fast bins.
• 10 fast bins for small chunks (< 88 bytes) of one size.
• 64 tcache bins for chunks between 24 and 1032 bytes in size. Each bin can hold up to 7 chunks of a given size.

Since the chunks are allocated and freed randomdly rather than sequentially, the memory allocator keeps track of the chunks using doubly (in the case of the small, large and unsorted bins) and singly linked lists (in the case of fast and tcache bins). The doubly-linked lists are particularly useful in use-after-free exploits because the head of the list is an address inside libc. By knowing where part of libc is located in memory, the base address of libc can be calculated and from there, any symbol inside libc becomes available by simply adding the offset to the base.

The allocator is designed to prefer allocating new memory from the bins, rather than from unused memory. When it receives a request through malloc, it attempts to allocate memory in the following order:

1. tcache bin
2. Fast bin
3. Unsorted bin

Note

tcache was introduced with GLIBC 2.26. Versions prior to this only have fast bins available.