Heap Exploitation: Getting started

Overview

A chunk is the name given to a block of memory that is managed by the heap. When you call the malloc function, the memory you get back actually comes from a chunk.

Each chunk is a small part of the heap and follows a specific structure. This structure helps the allocator know how big the chunk is, whether it’s in use or free, and where the next chunk is.

In memory, a chunk isn’t just raw space—it includes metadata that the allocator uses to manage things properly. This metadata is stored along with the chunk itself, just before the area that your program uses.

Here’s what a basic chunk structure looks like:

1
struct malloc_chunk {
2

3
  INTERNAL_SIZE_T      mchunk_prev_size;  /* Size of previous chunk (if free).  */
4
  INTERNAL_SIZE_T      mchunk_size;       /* Size in bytes, including overhead. */
5

6
  struct malloc_chunk* fd;         /* double links -- used only if free. */
7
  struct malloc_chunk* bk;
8

3 collapsed lines
9
  /* Only used for large blocks: pointer to next larger size.  */
10
  struct malloc_chunk* fd_nextsize; /* double links -- used only if free. */
11
  struct malloc_chunk* bk_nextsize;
12
};

To keep things simple and avoid confusion, I’ve left out the last two fields in the malloc_chunk structure. But for now, you only need to focus on the four most important parts:

• prev_size – the size of the previous chunk (used when it’s free)

• chunk_size – the size of the current chunk, including some flags

• fd – forward pointer (used when the chunk is free and part of a bin)

• bk – backward pointer (also used in bins for linking chunks)

These four fields play a key role in how the heap keeps track of memory and manages free chunks. Don’t worry if they sound a bit abstract right now—we’ll go over each one in more detail shortly. you can see how they actually work in practice.

Also, you can take a look at the image below to get a better idea of what a chunk looks like in memory and how these fields are laid out.

From the image above, we can see that a chunk consists of two main parts: metadata and user data.

The metadata (aka chunk header) part contains information used by the memory allocator, such as prev_size and size. These fields are not part of the memory you directly use in your program—they’re used internally to keep track of the chunk’s size, status, and position in the heap.

In addition, we can also see that the heap grows upward in memory. This means that each new chunk is placed after the previous one, following a continuous order. Older chunks remain at lower memory addresses, while newer chunks are added at higher addresses.

But wait!! Earlier we saw that a malloc_chunk includes both fd and bk pointers. So why aren’t they shown in the image above? The answer is those fields only become relevant when a chunk is freed.

When a chunk is in use (allocated), the space where fd and bk would normally be is part of the user data. But once the chunk is freed, that space is reused by the allocator to store fd (forward pointer) and bk (backward pointer), which are used to link free chunks together in bins.

So if you’re looking at an allocated chunk in memory, you won’t see fd and bk but they’ll show up once the chunk is no longer in use.

We can look at the image below to easily visualize what a free chunk will look like:

We will see that there will be two more things appearing, fd (forward pointer) and bk (backward pointer). As the name suggests, these two pointers will point to the previous and next chunks in the free list (I will explain this more clearly when we get to the bins section).

Size bits

1
/*
2
   Bits to mask off when extracting size
3

4
   Note: IS_MMAPPED is intentionally not masked off from size field in
5
   macros for which mmapped chunks should never be seen. This should
6
   cause helpful core dumps to occur if it is tried by accident by
7
   people extending or adapting this malloc.
8
 */
9
#define SIZE_BITS (PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)

We can see in the chunk layout image above that there are letters like A, M, and P shown next to the size field. These letters represent internal flags that are stored inside the chunk’s size value. They’re not part of the actual size but are packed into the same field for efficiency. This is where SIZE_BITS comes in. SIZE_BITS is a bitmask used to mark which bits in the chunk’s size field are reserved for internal flags. These flags help the allocator keep track of extra information about the chunk.

When you want to get the real size of a chunk (excluding the flags), you need to perform a bitwise AND (&) between the chunk’s size and the inverse of SIZE_BITS. This operation clears the flag bits and leaves you with just the actual size.

The flags stored inside the size field include:

• PREV_INUSE (P - 0x1): This bit tells whether the previous chunk is currently in use.

• IS_MMAPPED (M- 0x2): Indicates whether this chunk was allocated using mmap instead of the heap.

• NON_MAIN_ARENA (A - 0x4): Marks whether the chunk is part of a non-main arena, which can happen in multi-threaded programs.

These flags are packed into the same field as the chunk size, so we have to remove them first before we can get the real size value.

Demo

And to understand better, we will go into the following demo. We will have the source code as follows, copy it and compile it in the Docker environment I left above.

1
// gcc demo.c -no-pie -o demo -g
2
#include <stdio.h>
3
#include <stdlib.h>
4
#include <string.h>
5

6
int main()
7
{
8
    char *ptr1 = malloc(0x20);  // <-------- Chunk size will be 0x30 (0x10 metadata)
9
    char *ptr2 = malloc(0x200);
10
    char *ptr3 = malloc(0x2000);
11
    char *ptr4 = malloc(0x20000);
12

13
    strcpy(ptr1, "Hello World");
14

15
    return 0;
16
}

Debug it in gdb and set a breakpoint at the malloc function. You can do this by running the following command in the terminal:

1
pwndbg> bp *main+13
2
pwndbg> run
3
pwndbg> vmmap
4
LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
5
             Start                End Perm     Size Offset File
6
          0x400000           0x401000 r-xp     1000      0 /root/demo
7
          0x600000           0x601000 r--p     1000      0 /root/demo
8
          0x601000           0x602000 rw-p     1000   1000 /root/demo
9
    0x7ffff79e2000     0x7ffff7bc9000 r-xp   1e7000      0 /lib/x86_64-linux-gnu/libc-2.27.so
10
    0x7ffff7bc9000     0x7ffff7dc9000 ---p   200000 1e7000 /lib/x86_64-linux-gnu/libc-2.27.so
11
    0x7ffff7dc9000     0x7ffff7dcd000 r--p     4000 1e7000 /lib/x86_64-linux-gnu/libc-2.27.so
12
    0x7ffff7dcd000     0x7ffff7dcf000 rw-p     2000 1eb000 /lib/x86_64-linux-gnu/libc-2.27.so
13
    0x7ffff7dcf000     0x7ffff7dd3000 rw-p     4000      0 [anon_7ffff7dcf]
14
    0x7ffff7dd3000     0x7ffff7dfc000 r-xp    29000      0 /lib/x86_64-linux-gnu/ld-2.27.so
15
    0x7ffff7fee000     0x7ffff7ff0000 rw-p     2000      0 [anon_7ffff7fee]
16
    0x7ffff7ff6000     0x7ffff7ffa000 r--p     4000      0 [vvar]
17
    0x7ffff7ffa000     0x7ffff7ffc000 r-xp     2000      0 [vdso]
18
    0x7ffff7ffc000     0x7ffff7ffd000 r--p     1000  29000 /lib/x86_64-linux-gnu/ld-2.27.so
19
    0x7ffff7ffd000     0x7ffff7ffe000 rw-p     1000  2a000 /lib/x86_64-linux-gnu/ld-2.27.so
20
    0x7ffff7ffe000     0x7ffff7fff000 rw-p     1000      0 [anon_7ffff7ffe]
21
    0x7ffffffde000     0x7ffffffff000 rw-p    21000      0 [stack]
22
0xffffffffff600000 0xffffffffff601000 r-xp     1000      0 [vsyscall]

We see that before malloc is executed for the first time, there is no such thing as a heap. Because as mentioned before, the heap only really appears when we execute malloc for the first time. Don’t worry about this, because I will explain how malloc works in the next section How malloc and free work. For now, just know that, before malloc is executed for the first time, there is no such thing as a heap.

malloc for the first time:

1
pwndbg> vis
2
0x602250        0x0000000000000000      0x0000000000000031      ........1.......
3
0x602260        0x0000000000000000      0x0000000000000000      ................
4
0x602270        0x0000000000000000      0x0000000000000000      ................
5
0x602280        0x0000000000000000      0x0000000000020d81      ................         <-- Top chunk
6
pwndbg> vmmap
7
LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
8
             Start                End Perm     Size Offset File
9
          0x400000           0x401000 r-xp     1000      0 /root/demo
10
          0x600000           0x601000 r--p     1000      0 /root/demo
11
          0x601000           0x602000 rw-p     1000   1000 /root/demo
12
          0x602000           0x623000 rw-p    21000      0 [heap]
13
    0x7ffff79e2000     0x7ffff7bc9000 r-xp   1e7000      0 /lib/x86_64-linux-gnu/libc-2.27.so
14
    0x7ffff7bc9000     0x7ffff7dc9000 ---p   200000 1e7000 /lib/x86_64-linux-gnu/libc-2.27.so
15
    0x7ffff7dc9000     0x7ffff7dcd000 r--p     4000 1e7000 /lib/x86_64-linux-gnu/libc-2.27.so
16
    0x7ffff7dcd000     0x7ffff7dcf000 rw-p     2000 1eb000 /lib/x86_64-linux-gnu/libc-2.27.so
17
    0x7ffff7dcf000     0x7ffff7dd3000 rw-p     4000      0 [anon_7ffff7dcf]
18
    0x7ffff7dd3000     0x7ffff7dfc000 r-xp    29000      0 /lib/x86_64-linux-gnu/ld-2.27.so
19
    0x7ffff7fee000     0x7ffff7ff0000 rw-p     2000      0 [anon_7ffff7fee]
20
    0x7ffff7ff6000     0x7ffff7ffa000 r--p     4000      0 [vvar]
21
    0x7ffff7ffa000     0x7ffff7ffc000 r-xp     2000      0 [vdso]
22
    0x7ffff7ffc000     0x7ffff7ffd000 r--p     1000  29000 /lib/x86_64-linux-gnu/ld-2.27.so
23
    0x7ffff7ffd000     0x7ffff7ffe000 rw-p     1000  2a000 /lib/x86_64-linux-gnu/ld-2.27.so
24
    0x7ffff7ffe000     0x7ffff7fff000 rw-p     1000      0 [anon_7ffff7ffe]
25
    0x7ffffffde000     0x7ffffffff000 rw-p    21000      0 [stack]
26
0xffffffffff600000 0xffffffffff601000 r-xp     1000      0 [vsyscall]

After malloc the heap appears and so on for subsequent mallocs new chunks will be allocated but if you pay attention to the malloc(0x20000) you will not see it when using the vis command. That is because the requested size is too large and malloc cannot extract a part from topchunk (I will explain about topchunk later), so it used vmmap to allocate that memory, and that memory will definitely have bit 2 turned on

Overview

Bins are used by malloc to manage free memory chunks efficiently. Each bin corresponds to a specific size class, allowing quick allocation and deallocation of memory.

Fastbins

Fastbins are a memory management mechanism used by malloc to handle small-sized memory allocations very efficiently. They are designed to make allocation and deallocation of small memory chunks extremely fast, which is why they are called “fast” bins. It consists of several singly linked lists, each one storing freed memory chunks (also known as “free chunks”) of a specific size. Instead of returning small freed memory back to the system or main memory pool immediately, they are quickly stored in these fastbins for reuse.

On 64-bit systems (x64), there are typically 7 fastbins, indexed from 0 to 6. Each index corresponds to a specific chunk size (includes metadata). The sizes are as follows:

Each fastbin is managed as a singly linked list, and the head of each list is stored in the thread’s arena. The links between the chunks are stored inline, meaning the first 8 bytes (on 64-bit systems) of the chunk’s user data are reused to store a forward pointer (fd). This pointer links to the next chunk in the same fastbin. If the fd is NULL, it indicates the end of the list.

The fastbins operate like stacks, following a Last-In, First-Out (LIFO) structure. When you free() a chunk that qualifies for a fastbin (i.e., it falls within the fastbin size range), the chunk is added to the top of the corresponding fastbin list. Later, if you malloc() a chunk of the same size, glibc will return the most recently freed chunk from the top of the list.

1
pwndbg> fastbins
2
fastbins
3
0x20: 0x602040 —▸ 0x602020 —▸ 0x602000 ◂— 0
4
pwndbg> dq 0x602040
5
0000000000602040     0000000000000000 0000000000000021
6
0000000000602050     0000000000602020 0000000000000000
7
                                ^------------------------------------- forward pointer
8
0000000000602060     0000000000000000 0000000000020fa1 <----------  top chunk size
9
0000000000602070     0000000000000000 0000000000000000
10
pwndbg> dq 0x602020
11
0000000000602020     0000000000000000 0000000000000021
12
0000000000602030     0000000000602000 0000000000000000
13
                                ^------------------------------------- forward pointer
14
0000000000602040     0000000000000000 0000000000000021
15
0000000000602050     0000000000602020 0000000000000000
16
pwndbg> dq &main_arena 18
17
00007ffff7dd0b60     0000000000000000 0000000000000001
18
00007ffff7dd0b70     0000000000602040 0000000000000000
19
                                ^------------------------------------- The head of the fastbin list for `0x20-sized` chunks
20
00007ffff7dd0b80     0000000000000000 0000000000000000
21
00007ffff7dd0b90     0000000000000000 0000000000000000
22
00007ffff7dd0ba0     0000000000000000 0000000000000000
23
00007ffff7dd0bb0     0000000000000000 0000000000000000
24
00007ffff7dd0bc0     0000000000602060 0000000000000000
25
                                ^------------------------------------- top chunk address
26
00007ffff7dd0bd0     00007ffff7dd0bc0 00007ffff7dd0bc0
27
00007ffff7dd0be0     00007ffff7dd0bd0 00007ffff7dd0bd0

If the tcache is enabled and the relevant tcache bin is not full, the freed chunk goes to the tcache. Conversely, if the tcache bin is full, the chunk is pushed into the fastbin. Furthermore, when glibc services a malloc() request, it first checks the tcache. If no suitable chunk is available there and the requested size matches a fastbin size, it then proceeds to check the fastbin before moving on to other bins or the main heap.

Tcache

Tcache (per-thread cache) was first added in GLIBC version 2.26. It is a memory caching system that helps speed up memory allocation and freeing. Instead of using shared memory areas like the main arena or fastbins, each thread gets its own tcache. This reduces competition between threads when they use malloc or free.

A tcache is made up of 64 bins. Each bin holds free memory chunks of a specific size. These sizes range from 0x20 to 0x410. Each bin is a simple linked list, and it keeps track of chunks that can be reused quickly. The bins are managed by a structure that also includes an array of counters. Each counter tells how many chunks are in a bin. For example, the first counter shows how many 0x20-sized chunks are stored, the second counter shows how many 0x30-sized chunks, and so on.

There is a limit to how many chunks each bin can store, and this is controlled by a setting called tcache_count. If a bin reaches this limit—by default, 7 chunks—then any new chunk of that size will not be added to that tcache’s size. Instead, it will go to the normal memory system, such as fastbins, etc. One thing we need to note that when malloc looks for memory, it first checks the tcache. If the tcache does not have space or the right chunk, it will continue to search other bins.

Unsortedbin

An unsortedbin is a doubly linked, circular list that holds free chunks of any size. The head and tail of an unsortedbin reside in its arena whist fd & bk links between subsequent chunks in the bin are stored inline on a heap

From the image above, the order of free chunks will be A, B, C, D from left to right. And the green arrow will represent the forward pointer, the pink arrow will represent the backward pointer.

When a memory block is freed and cannot go into tcache (because the tcache is full or the block is too big — 0x420 or more by default), it is put at the beginning of the unsortedbin. Howerver, in older versions of GLIBC (version 2.25 or lower, by default), where tcache is not used, freed memory blocks are put into the unsortedbin if they are too big for the fastbin (size 0x90 or more, by default).

When a program asks for memory, the system first looks in tcache, fastbins, and smallbins if the size fits. If nothing is found there, it then checks the unsortedbin, but before checking the largebins. The system starts searching from the end of the unsortedbin and goes to the beginning. If it finds a memory chunk that exactly matches the requested size, it uses that chunk and stops searching. If it doesn’t find a match, the chunk is moved (sorted) to a smallbin or largebin, depending on its size.

If the memory chunk found during an unsortedbin search doesn’t exactly match the requested size, but it’s the last chunk and it’s big enough to split, the system will split it. The part that is given to the program is used, and the leftover part (the remainder) is put back at the beginning of the unsortedbin to be used later.