Tales from the heap: main_arena, fastbins, debug flags

OK so the next part of our flow chart is the fastbins.

They act very similarly to the tcache bins with a few exceptions:

the heads of the fastbins live in the main_arena
there isn't a count of how long the linked lists are
they get consolidated into unsorted bins at key times
the security checks against double frees aren't as strong

Here is the main arena in pictures:

My goals for the day:

I'd like you to trigger errors using a debug version of glibc so you can learn how to see what security checks you trigger.

I'd like you to get as comfy with the main_arena as you were with tcache (at least for the fastbin part).

I'd like you create a fast_bin dup using a double free free(a); free(b); free(a);

Heap Vulnerability Playground

OK so I made this for you in order to let you navigate the flow chart with ease.

This playground gives you way too much rope and you can see it suffers from Use After Free, but not heap smashing (the ability to overflow your intended area), well except by one single null byte (which is often enough).

We can use this template to try many different exploits with any number of distinct glibc copies.

Traceback: glibc with debug symbols

So in my /glibcs directory with all of the various glibcs there is a special folder called malloc which has a single source file malloc.c.

If, when you copy the library into your directory you also bring a copy of malloc.c we can see what lines of malloc.c are causing problems for us.

OK here's my instructions for seeing the double-free protection in fastbins with your own eyes:

Compile the heap playground: gcc heapvuln.c -o playground
Let's use glibc_2.27_no-tcache (so we don't have to fill the tcache to see fastbins)
copy ld.so.2 libc.so.6 and malloc.c into the same directory as playground
patchelf --set-interpreter ./ld.so.2 --set-rpath . playground
Now run it with gdb: gdb ./playground
run
Allocate a single chunk into index 0 of size 24 (give it any data)
Now free chunk in index 0
Now free it again
You'll get an error (screenshot below)
Set the frame of the traceback: f 4
Show the code: context code

CONGRATS!! This is the best heap learning tool I can give you

Being able to see and debug your exact error in the exact source code is the best way to discover the security checks you will trigger as you go about making exploits!

fastbins and the main_arena

Now technically there can be more than one arena, hence the name main_arena for the one that always exists.

The main_arena is the struct, just like the tcache struct. That lives inside of glibc and holds the heads of all of the bins/linked lists (it also holds other cool meta data)

So let's see it in action.

Start again with gdb ./playground and make a small chunk then free it. Let's see it in two ways:

bins and dq &main_arena 16

OK, now we can inspect the true main_arena and validate the way that the ascii struct diagram works:

Aside: making a leak

Let's manufacture a glibc leak using the unsorted bins

Make a chunk larger than the fastbin size range
Make a buffer chunk (so it doesn't get absorbed into the top chunk)
free the large chunk
view the contents of the large chunk (use-after-free)
Check that address and see that it's main_arena
You can even do telescope your_leak_here to see what the offset into main_arena is.

fastbin-dup / double-free

OK now finally get around the security check by doing a free(smallchunk) free(anothersmallchunk) free(smallchunk)

We will explore just how deadly this is next time.

fastbin dup works like this:

      A = malloc(somefixedsize);
            B = malloc(somefixedsize); 
            free(A); 
            free(B); 
            free(A); 
            C = malloc(somefixedsize)//will be A
            fgets(C, 8, stdin)//send target to C
            D = malloc(somefixedsize)//D will be B
            E = malloc(somefixedsize)//will be A again
            F = malloc(somefixedsize)//will be target!