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

Welcome .... Click here to logout


tcache recap:

UAF recap

Finally we started to look at Use-After Free

UAF is a catch-all term for bad things that happen if a developer does NOT clear their pointers after freeing.

PWN recap

Recall that all exploits must do three things:

  1. Deal with Address Randomization
  2. Be able to drop a payload (i.e. Write-What-Where)
  3. Change the Instruction Pointer to a cool target

So far in our heap problem we've got a leak of a heap address and a leak of a glibc address.

OK so next we need a write-what-where

tcache poisoning

AKA Use-After Free part 2

Alright here we go...

Last time we simply VIEWED a chunk after it was freed and got some nice address leaks.

THIS TIME if we can EDIT an already freed chunk what harm can we do?

Well it's a linked list, so we can just replace the address...

When you write a new address into a tcache bin we call that TCACHE POISONING

Here is the idea:

Let's do it. Use the playground with gdb, malloc 3 chunks, free 2 of them, edit (after free) one those and put the address 0xDEADBEEF into the chunk. Then inspect the bins. Finally malloc twice and observe a segfault (when the address 0xDEADBEEF is interpreted the program will crash).

Do today's tcache PCP


Come do some live ones