Fastbin Dup

OK the idea is simple enough:

malloc 7 times (for the tcache)
A = malloc
B = malloc
free the first 7
free(A)
free(B)
free(A)

This let's us now have A in the fastbins twice.

That means that our next malloc gives us a.... Use After Free!

OK so let's use it.

First one tweak...

I commented these two lines...

      
    //printf("first payload?\n> ");
    //fgets(arr[idx], sz, stdin);

This is to help me with leaks, I think there's some super smart way to not need it, but this will help without a huge change.

Our Tools: WWW and VAF

Write-What-Where and View-After-Free

What do we need?

We need a glibc leak.

What sort of leaks can we get?

We can view chunks in the fastbins.

What addresses are typically in the fastbins?

Heap addresses...

ugh...

So we need to fake a chunk of size 0x420 and get glibc to put that fake chunk into the unsorted bin.

How on earth do we do that?

I can think of two possible ways:

Method 1: Use the "fastbins consolidate" fact we learned Monday, get the fastbins to consolidate and the big chunk will go into the unsorted bin, THEN be returned to us.
Method 2: Use a heap leak AND a Write-What-Where to edit the size of a chunk and make it larger

Now Write-What-Where with fastbin dup takes an extra step that will take some effort to teach.

glibc Leak via Fastbin consolidation

Let's try it.

At first I thought maybe I would need to do a dup then get my dupe to be at the head of something nefarious. But I think... I think... that this leak is just a freebie. It's not even a use-after-free it's actually a new kind of secure software design rule: BEWARE UNITIALIZED DATA

malloc(24) 7 + 33 + 1 times (7 for the tcache, 33*0x20 is 0x420, and 1 for protection from the top chunk)
free() 7 times to fill the tcache
free() 33 times to make enough fastbin chunks so that the consolidated chunk is big enough
malloc(0x418)
Just view the data in our new big chunk
Parse the leak

I learned this from our playing around on Monday. It looked like the consolidated chunk actually had glibc addresses in it immediately after malloc... If this works, hooray. Not a single thing we did was wrong or broke any rules... yet...

Since we haven't really changed the libc and the leak is main_arena+96 we can keep the leak processing we've done the last couple times:

WWW with Fastbin

Alright the next headache...

OK what does this mean?

suppose you have stuff in the 0x30 fastbin
you do a malloc and malloc would like to give you the address X
they know we hackers are around so they validate X
How? They look for an 0x31 (or 0x3f or 0x30) in the size field of the chunk.
NOTE: unlike tcache, fastbin addresses are ACTUALLY 16 bytes before the user data
(This is because malloc needs to check the size of the chunk (and the previous chunk))

Take a look at this:

See how the tcache is at 0x360 and the fastbin is at 0x370, fastbins are off by 16 compared to our tcache.

OK SO what does this mean for us?

Well we can't actually target EVERY address...

In fact we can only "target" addresses that are 8 bytes before a valid p64(size) which also matches the bin's size.

But we have a REAL target that certainly won't be near one of these sizes, BUT MAYBE... somewhere before our REAL TARGET is a valid fake p64(size).

We have a pwndbg function for that!

Use fake_fast_chunk to find a valid target NEAR the malloc_hook or free_hook

Turns out 51 bytes behind the malloc_hook is a decent target... because glibc addresses tend to end with 0x7f or 0x7e.

Well... I spent a lot of time trying to drop a one gadget to the malloc_hook and couldn't get the registers to line up.

Back to our old friend tcache

OK so tcache_poisoning

If we leak a heap address

Drop FAKE size fields in chunks we're allowed to write in nearby the target

Then drop a free_hook into a tcache bin

We can do our old trick and free("/bin/sh")

I'll try to do this live...

Forever Goals: