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.

General Write-What-Where in the HEAP

Our WWW goal is to do a MALLOC and get the address they return to us to be a TARGET ADDRESS.

So how is any address malloc returns predictable?

So a general plan looks vaguely like:

• MALLOC a chunk
• FREE that chunk into a linked list
• EDIT that free'd chunk to put a TARGET ADDRESS into
• MALLOC (at least twice) to get your TARGET ADDRESS returned to the user for EDITING

The specifics will vary by which specific bin (linked-list) we're targeting, our version of glibc, and constraints of the binary.

Class 23: WWW via tcache-poisoning

(Given a USE-AFTER-FREE)

Our "easy" to "real" narrative structure:

The "easy" essence is to EDIT a linked list:

• MALLOC a chunk
• FREE that chunk
• EDIT that chunk with TARGET ADDRESS
• MALLOC once to pop the address of that chunk
• MALLOC again to receive the TARGET ADDRESS

Let's see the whole linked list at each stage of this SIMPLE plan.

The simple trick breaks in three ways:

• PROBLEM 1: nothing happens (this is the TOP CHUNK stuff -- easy fix just put up a wall)
• PROBLEM 2: the TARGET ADDRESS is just not returned (tcache count requires ANOTHER malloc)
• PROBLEM 3: we can't just type TARGET ADDRESSES (pwntools for heap)
• PROBLEM 4: the ADDRESS has been corrupted (this is just the encryption stuff do SHIFT XOR)

For now we can downgrade our glibc version to avoid problem 3. So let's work in glibc 2.31

Today's PCP gives you a target address and a desired value (0xdecafbad), it has a win function that will trigger if you have changed the target address to have the desired value.

Problem 1: TOP CHUNK

OK this is just the wall again so easy peasy:

• MALLOC the first chunk
• MALLOC a "barrier" chunk
• FREE the first chunk
• EDIT the first chunk with TARGET ADDRESS
• MALLOC once to pop/return the address of that first chunk
• MALLOC again to receive the TARGET ADDRESS

No problem just one extra note in our two note samba

Problem 2: the tcache bin count

So we should be able to SEE OUR TARGET address in the appropriate tcache bin.

Use bins to SEE A TARGET ADDRESS in the appropriate tcache bin.

But the next malloc just returns another boring new chunk from the heap. Why?

BECAUSE the TCACHE COUNT was 0 not 1, so it didn't even look in the tcache bin for a chunk.

So easy enough, we just need another dummy chunk.

• MALLOC the first chunk
• MALLOC the second dummy chunk
• MALLOC a "barrier" chunk
• FREE the first chunk
• FREE the second dummy chunk
• EDIT the first chunk with TARGET ADDRESS
• MALLOC once to pop/return the address of that first chunk
• MALLOC again to receive the TARGET ADDRESS

Problem 3: need unprintable TARGETS

Adapt this starter script to our world, maybe add a check_target handler.

Our stuff will now look like:

• malloc(0, 24, "first")
• malloc(1, 24, "second")
• malloc(2, 24, "BARRIER")
• free(0)
• free(1)
• edit(0, p64(TARGET))
• malloc(3, 24, "don't care")
• malloc(4, 24, p64(0xdecafbad))
• check_target()

PROBLEM 4: encrypted pointers?

We're just going to solve this by ignoring it for now, use GLIBC 2.31

In the future we'll solve this by first making a HEAP LEAK then encrypting our target address with:

      TARGET ^ (HEAP >> 12)
    

Appendix

Our HEAP PLAYGROUND:

Heap Reference Guides:

Secret Tale of the 5 bins: fastbins

fastbins are a lot like tcache bins. They are designed for quick reuse more than recycling.

• the fastbins are singly-lined lists
• they are stored in glibc's MAIN_ARENA
• there is one for the sizes 0x20, 0x30, ... , 0x80
• there is NO LIMIT to the number of chunks in the fastbins
• so to avoid fragmentation the fastbins CONSOLIDATE regularly
• that is they look for chunks near each other that can be marged into a larger chunk
• the consolidated chunks end up in the unsorted bin (story soon)
• to get a chunk into the fastbins you need to overload the 7 chunks in the tcache bin of that same size
• there are two security checks:
• 1) when you add a chunk into a fastbin it tries to make sure it's not the same address as the previous chunk
• (solution: A->B->A)
• 2) when it returns an address from the fastbin it double checks that the returned address has the right "size" meta data
• (solution: find_fake_fast)