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

Challenges to the comfort of Mom's:

• glibc 2.32 introduces "encryption" to tcache
• No UAF but has Double Free...
• **glibc 2.34+ has no FREE_HOOK**
• Can't control the size of your mallocs
• Only chunk overflow
• Only get poison null byte

Latest glibcs have no FREE_HOOK

Let's check our compass:

• CONQUER ADDRESS RANDOMIZATION, unsorted bin + encryption key: m(B),m(s),f(B),f(s),m(B),v(B)//libc,m(s),v(s)//heap_key
• WRITE-WHAT-WHERE using reusable BOTCAKE (consolidate, free from middle, overlap, back to TCACHE-POISONING) (Tyler observed that the same way we got leaks we can do old-fashioned mom's btw)
• CONTROL INSTRUCTION POINTER targeting the EXIT_FUNCS (gotta teach you this one)

Useful gdb tools:

• dt 'struct exit_function_list'
• dt 'struct exit_function'
• dt 'tcbhead_t'
• fsbase (close to but before the glibc base)
• p *(tcbhead_t*)$fs_base
• :setw -g

Useful pwntools things:

• libcdb.unstrip_libc("./libc.so.6")
• elf.sym.__exit_funcs
• elf.sym.initial

ASIDE: Reusable BOTCAKE

I want to highlight that BOTCAKE can be used over and over for many WWWs

ASIDE: unstripping glibc

So most of the glibc's we target are the LTS Ubuntu copies, as they are the workhorse for the internet.

Most of the time those glibcs are "stripped" which hides certain symbols making it harder to find things.

We can UNSTRIP a glibc using pwntools and the widely available "debug symbols"

Let's target the LATEST 2.41 glibc which requires the following two lines from pwntools:

• libcdb.DEBUGINFOD_SERVERS=["https://debuginfod.elfutils.org/"]
• libcdb.unstrip_libc("./libc.so.6")

The __exit_funcs

Alright this story has two parts:

• The Exit Functions
• the Thread Control Block

OK this shows how the exit funcs look, where they live (libc.sym.initial), and how union sort of works.

So what are they? These are functions that will get called, with or without an argument based on the "flavor", when the program EXITs.

Sweet so this is a new target in life after FREE_HOOK?

Well... those addresses look funky... introducing:

TCB Pointer Guards

Alright one last security check to get around...

The addresses in the exit_funcs have been encrypted.

The encryption looks like this:

There's a rotate left of 17 bits after an XOR with the pointer guard.

The pointer guard is a random value which LITERALLY LIVES NEXT DOOR to the stack canary!

Here's what that looks like:

The TCB lives JUST BELOW glibc, the offset is 10432 (surprisingly consistent between versions...)

At TCB +0x30 is the pointer guard (+0x28 is the infamous stack canary)

That pointer guard is the XOR key for the exit funcs... SO here's how we handle our exploits:

The TWO WWW targets

• WWW to put p64(0) into the pointer_guard location (glibc - 10432 + 0x30)
• WWW to put p64(0)+ p64(1) + p64(4)+encrypt(system, 0) + p64(binsh) + p64(0) over the EXIT_FUNCS

One WWW was to disable the key, the other to drop system("/bin/sh") in as an exit_function.

That will make a "flavor 4" (function with argument) function into our list, with the function being system and the argument the location of a "/bin/sh"

Samba Gist

(Link to) Heap Reference Materials

The Bins as Diagrams

Heap Flow Charts:

HEAP PLAYGROUND and STARTER SCRIPT: