Don't like this style? Click here to change it! blue.css

Welcome .... Click here to logout

Forever Goals:

This week's constraint:

NO to USE AFTER FREE, YES to double-free

Fastbin Dup

OK the idea is simple enough:

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...


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:

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

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?

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...