Daily Reminder: Mom's Spaghetti

Our compass through all of this is the desire for the following comfort food:

• **CONQUER ADDRESS RANDOMIZATION** by a USE-AFTER-FREE vulnerability to leak a glibc address
• WRITE-WHAT-WHERE using TCACHE-POISONING for arbitrary writing to glibc
• CONTROL INSTRUCTION POINTER by overwriting the FREE_HOOK in glibc with system where "/bin/sh" is written in the free'd chunk

You're babies today and we're going to learn the warmth and love of the dining room table. So that as you venture into the wilderness you'll do your best to recreate this ritual in ever harsher environments.

Today's Goal: How do we generate a leak?

(Given a USE-AFTER-FREE)

It's "easy" just:

• Free a chunk
• View that chunk after freeing it

Of course, then you need to know a few lower level things.

Questions this raises:

• Q1: How do we do that, exactly? Just what are the mechanics?
• Q2: I did the simplest thing, it didn't work. Why?
• Q3: What exact address is put into a free'd chunk?
• Q4: Which segments of memory can this possibly leak from?
• Q5: How well do I need to know everything to just do this one thing?
• Q6: I got a partial leak. Why? What do I do about it?

TLDR: The Samba Melody:

For some carefully chosen size x

• A = MALLOC(x)
• B = MALLOC(x)
• C = MALLOC(x)
• FREE(A)
• FREE(B)
• VIEW(B)

To understand why we'll need more intel.

Typical PWN Heap mechanics:

Our HEAP PLAYGROUND:

This is a typical CTF style setup. Where we have this sort of smallest possible CRUD (Create, Read, Update, Destroy) setup.

Here is a sort of starter pwntools script for this kind of problem:

Just Do It?

So let's try to get a leak on this program. The plan is to ask for space, free that space, view that space (this is the coder's vulnerability BTW).

Some stuff could go wrong.

Let's run this in gdb/pwndbg and look at the heap after the various mallocs and frees.

Deep Dive into the details

OK answering the questions.

Q1: The mechanics

malloc chunks, free chunks, view those free'd chunks.

Q2: The simplest thing didn't work, why?

Some possible reasons:

• The chunk might literally disappear.
• The address might be mangled.
• The address would be a heap address (we want glibc).

Mental models to explain those 3:

• The last chunk, when freed, gets absorbed into the top chunk
• If your version of glibc is 2.32+ then addresses are "encrypted"
• Free'd chunks go into different "bins" and the most common bin (the tcache bin) lives entirely in the heap

OK, but how would you check any of that on your own?

Well below are some useful guides.

ALSO it is nice to know the:

Tale of the 5 bins

We should probably make a bookmark to learn how each of these 5 are used and why and various subtleties.

But let's just learn their names and fill in details as we go.

• tcache - super quick, one per thread, starts in the heap
• fastbins - performance based singly linked quick list (glibc)
• unsorted bin - the staging bin for later sorting (glibc)
• small bins - slightly more common oldest form (glibc)
• large bins - the oldest form (glibc)

Q3 and Q4: What exact address is put into our chunk that we leak from?

TCACHE puts the address of the previous "HEAD" into the chunk, but that address is ALWAYS in the heap segment.

FASTBINS act the same exact way.

The first UNSORTED BIN chunk links to GLIBC! Twice in fact!

Later things added to the UNSORTED BIN will link to other chunks (it's doubly circularly linked and the head starts in glibc)

SMALL BINS are also linked to glibc and each other but a slightly different glibc address based on the size.

LARGE BINS are also linked to glibc and each other (and "fast-linked" to other size chunks) but a slightly different glibc address based on the size.

Q5: How well do I need to know this crap to get a leak?

The easiest leaks might be all you need (if a heap leak is good enough). But if you need a glibc leak you'll need to know HOW to force a chunk into the unsorted bin.

If you need to get a bin into the SMALLBINS or into the LARGEBINS (Q6 will give you a why) then you'll need to know even more.

So if you are lucky you don't need to understand, and the more debugging you need to do the more you need to understand to do that well.

Q6: My address was partial. What do I do now?

Sometimes, by bad luck, there is a null byte in your address. So when we print the leak the printf stops before giving you everything.

In that case you can try to move, intentionally into a DIFFERENT BIN so the address is just a little different.

If the null byte is in the randomized part of the address you can just run again and not be unlucky.

(Link to) Heap Reference Materials

The Bins as Diagrams

Heap Flow Charts:

HEAP PLAYGROUND and STARTER SCRIPT: