Class Notes CPEG 476/676 Spring 2023

HEAP RECAP:

Dynamic Memory is managed with the heap
It's all about recycling quickly without fragmenting
There are 5 types of "bins" (tcachebins, fastbins, unsorted bin, small bins, large bins but we barely know these so far)
bins are really just linked lists, the linked lists are stored using structs
In gdb with pwndbg we can see the heap using vis and we can also see the bins
The heap has the civilized and the wilderness and the "TOP CHUNK" holds the amount of wilderness left

tcache recap:

A set of singly linked lists called bins
Each linked list is just an address
The location of the address tells us the size of the "chunks" in that bin
The sizes that get stored this way are 0x20, 0x30, ..., 0x410
The tcache also keeps a count of how many chunks are in each bin
The counts are stored in 128 bytes, 2 bytes for the 0x20 count, then 2 bytes for the 0x30 count, etc.
The linked lists are last-in-first-out LIFO style
That is, we add chunks to the HEAD and we remove chunks from the HEAD

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.

If you can "view" a chunk even after freeing it, then if you free two chunks, you'll get a leaked heap address
If you can "view" a large chunk (bigger than 0x410) after freeing then you'll leak a glibc address
In newer glibc versions (>= 2.32) the addresses are XORed with a bit-shift of a heap address
You can undo this with the following python routine:

PWN recap

Recall that all exploits must do three things:

Deal with Address Randomization
Be able to drop a payload (i.e. Write-What-Where)
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:

Get a chunk to be freed and added to a tcache bin
See if you can EDIT an already freed chunk (Use-After Free)
Edit the first 8 bytes of the chunk which hold the fd pointer in the linked list
Now you have added your own TARGET address to the chain
malloc a couple times until malloc returns TARGET to you, the user
Write whatever you want (PAYLOAD) to TARGET

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