Don't like this style? Click here to change it! blue.css
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.
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.
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?
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.
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:
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!
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.
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...