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've done baseline mom's, level 2 is mom's with 2.32, level 3 is mom's with just double free. LEVEL 4 is double-free mom's but glibc 2.34+ that is the latest glibcs. They no longer have FREE_HOOK

• 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

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

Class ???: 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)
• CONTROL INSTRUCTION POINTER targeting the EXIT_FUNCS (gotta teach you this one)

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"

Last night I struggled for a bit to get the LATEST 2.39 LTS 24.04 copy unstripped, JD helped me figure out this:

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

I re-released LEVEL4.5 which is just LEVEL4 but with glibc 2.39 which will be with us for a long time. Check it out in the PCPs

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

Appendix

Our HEAP PLAYGROUND:

Heap Reference Guides: