Life without UAF

OK our goal this week:

In this one I'm checking to see if your pointer is still in use, and if I see no then I prevent reading and writing after freeing.

So our friend tcache poisoning won't work.

In fact, a whole lot has changed.

This week I want to teach you the exploit: Fastbin Dup

It looks like this on the surface:

      
            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!

That's what happens in the how2heap repo too

A dup (pronounced doop/dupe) is a way to CREATE UAF from some other smaller vulnerability.

If you can hold a chunk which is both free and in-use then you can UAF

We will accomplish this in many ways later (including fake chunks in the middle of in-use chunks), but the principle is always the same:

If you can edit meta-data or pointers you can do harm

BUT this story gets a little harder than I wanted pretty fast...

SO I'm going to give you a couple foundations to give you clear thinking in the next steps.

tcache vs fastbins in healthy land
inspecting the security checks
contrained leaking

What are fastbins?

How are they like tcache?

Fastbins are singly linked lists of chunks all the same size.

They act just like tcache in many ways.

Key Similarity: Made for speed, they never trigger the "prev in use" bit

How are they different?

OK tcache lived on the heap as a singly linked list with counts.

Fastbins live in glibc (the main arena) as singly linked lists with NO COUNTS.

Why have counts? To fight fragmentation

How do fastbins fight fragmentation? (Imagine 1 million tiny fast bin chunks in the worst orderings... ugh)

Whenever someone asks for something too big the fastbins CONSOLIDATE

Difference 1: tcache stored in heap with counts, fastbins in glibc (main_arena)

Difference 2: There might be a million fastbins cluttering up memory

Difference 3: fastbins have different security measures

Security Measures in fastbins

ALSO, how to check for yourself

This is our first time in the glibc source code really.

This one is basically just checking that you aren't freeing the same chunk twice in a row.

No problem we just do: free(a), free(b), free(a)

(Aside: why won't this ever be patched? Think millions of chunks)

This one is basically saying, hey if I'm handing you an address I'll just double check that the size matched the fastbin I'm pulling from.

Forever Goals:

This week's constraint:

NO to USE AFTER FREE, YES to double-free