So this is a static binary. It's got a lot of libc zipped up within itself, removing ret2libc and ret2plt and stuff like that. Disassembling main and ignoring all the extra libc functions, we see it prints the string about it being a large binary and then calls gets on rbp-0x100. So, buffer overflow obviously. But what do we ret to? How to pop a shell?

System, execve etc. all the stuff that may be useful for shell popping is removed from the binary's libc functions. That doesn't matter though.

The libc is big, and it has a lot of purposes. It'll need to do many things including syscalls. Because of this, libc is always a ROP gadget goldmine. Since this binary has most of libc in itself, this binary is also a ROP gadget goldmine.

Due to this, we can build a simple execve ROP chain to execve("/bin/sh",NULL,NULL), then cat flag.txt.

Flag: flag{radically_statically_roppingly_vulnerable}

EXPLANATION:

What I just used here is called Return Oriented Programming. ROP works by building chains of return addresses. When a program rets, it'll go to the next value off the stack as a return address. So, if our input is ever at the top of the stack, we can build chains of return addresses, causing it to continue ret-ing into the next location.

The ROP chain i used uses syscalls or system calls, the lowest level, used for special calls to the system, e.g opening files, writing to files, and in this case executing files.

The chain I just used is as follows. It uses the execve syscall since the function is not available. Remember 64-bit arguments are in rdi, then rsi, then rdx...

Our goal is to execute execve("/bin/sh",0,0) as a syscall

• pop rdi address - pop next value off the stack into rdi for first argument

• /bin/sh address - to be popped into rdi as first argument

• pop rsi address - pop next value off the stack into rsi for second argument

It takes an address and number in hex, then writes the number to the address. The hex is parsed by strtoull which will be useful later.

After writing, it calls sleep(0xf), then prints the address of alarm and calls exit. The address of alarm gives us a libc leak. Partial RELRO, so GOT overwrite is possible. Here's what we do:

1. Overwrite exit@got with main. When it attempts to exit after printing a libc pointer to us, it'll call main, giving us another write

2. Overwrite sleep@got with main(we couldn't do this before as alarm is called after sleep but we dont need anymore leaks) so that the alarm doesnt catch us out and our exploit is quick from then on

3. Overwrite strtoull@got with system so next time it tries to turn our input to hex it calls system on it

4. Enter /bin/sh as the next address

Shell will be popped, we can cat flag.txt.

Gets is called on rbp-0x90, there's a function called secret_recipe which reads flag.txt and prints it to stdout. So, just your standard ret2win, overflow 0x90 + 8 bytes of the buffer to overwrite the return address to that of secret_recipe

from pwn import *
NUM_TO_RET = 0x90 + 8
padding = b'A' * NUM_TO_RET
e = ELF("./pancakes")
#p = e.process()
p = remote('jh2i.com',50021)
p.recvlines(2)
p.sendline(padding + p64(e.symbols['secret_recipe']))
p.interactive()

Flag: flag{too_many_pancakes_on_the_stack}

Solved by Day - gg for the writeup :smile:

Flag found at the end

Given the name "space FORCE" this was probably meant to be house of force but I felt like that would be more complicated than what I ended up doing so I... didn't do that.

Instead, I went along the path of a more complex tcache poisoning attack.

Let's digest the program first before we look at how we are to attack it.

We have 5 functions:

• register account

• print account by UID

• print all accounts

I'm not gonna talk about launch rocket, since it seems rather useless and I didn't use it at all.

Register account

We choose a first name, last name, and can set the expiry if we want. Note the expiry, unlike the comment, is malloc-ed no matter what, it's just not initialised if we don't set the expiry. We can also set the comment, for this we get to specify the size and it gets malloced. Here are some representations of how accounts are stored:

UID

Simply represents the index of the account in the account array, which by the way is stored on the stack and has no cap.

Print account by UID

Specify UID(which is used as an index to grab the account) and the UID, first name and last name will be printed. Note that there's no checks at all on the UID and deleted accounts aren't removed from the array, the account counter is just decremented(read after free) but I ended up not using this, as the UID is only printed as an integer and thus not a lot of information can be reaped.

Print all accounts

Note that the program keeps an account counter, incrementing when an account is made, decrementing when the last account is deleted.(This is also how it keeps track of the last account). All accounts up to this counter are printed: UID, last name, first name But this time so is the expiry - day, year and month.

Ok, we've covered all the important functions. Let's dissect our two main vulns.

VULN 1

Malloc does NOT initialise data. Info leak! Left over pointers from a free chunk newly allocated remain. This allows us to get a heap leak by smartly handling expiries, which I'll explain below.

VULN 2

There is overflow when we make an expiry. 32 bytes are read into the month when only 16 should be read. This gives overflow of 15 bytes after the end of the expiry chunk(1 byte is reserved for null as fgets is used)

Let's dissect a little more into exactly how our data is stored on the heap.

So, we've already covered the account and expiry structs.

• Accounts are 0x70 size chunks(0x60 allocation)

• Expiries are 0x20 size chunks(0x10 allocation)

• Comments are malloc-ed to their exact size

So, how do we get this info leak?

Let's start off with two accounts, no comment. Heap is as follows:

Let's free them both, and take a look at the tcache

• 0x20 bin -> account 0 expiry -> account 1 expiry

• 0x70 bin -> account 0 -> account 1

Let's make another account, it'll be served pretty much on top of the old count 0. Let's again not set an expiry.

Now, remember how I said it just doesnt initialise when we dont set an expiry? This means in place of the day and year fields, will set a heap pointer! We can leak this pointer!:

• Printing all accs

• Extracting the day and year pointers

• Doing twos complement (as they may be displayed negative)

This gives us the heap base

> Ok.. ok, so we know the whereabouts of the heap. What about libc?

In hindsight this could've been done SOOO much simpler by forcing an unsorted bin chunk then doing the same sort of protocol as the 0x20 would be served by the unsorted bin but.. here we are. The 15 bytes of overflow past the expiry chunk lets us overwrite the size field of the next chunk (I didnt do anything here, just set it to what it already was) and then overwrite the 8 bytes afterwards. This can be used nicely for tcache poisoning, overwriting the next pointer of a tcache chunk.

What I did was:

• allocate an account with a 0xe0 sized comment

• freeed it

• allocated an account with

This account would be in around the same place, just below the old, freed, tcache comment chunk.

With the expiry overflow, we can overwrite the next pointer to execute tcache poisoning. Given my knowledge of the whereabouts of the heap, I used this to:

• go back

• overwrite the expiry pointer of chunk 0 to an existing unsorted bin chunk

So, we can set the next pointer to the address of the expiry pointer of chunk 0. Make a 0xe0 comment allocation, make one again - this will be on top of chunk 0's expiry pointer! Let's overwrite the expiry pointer with that of the unsorted bin chunk.

> Now, by printing all accounts, we also print the libc pointer hidden in the expiry(it'll be right at the month field).

> Note the 0xf0 tcache is utterly fried after this so we wont be making any 0xe0 allocations again.

Now, we've got heap AND libc!!! We just need the final piece - an arb write, preferable to write to free hook.

We can repeat this process again, but things get more complicated. Going back to getting an unsorted chunk, this is only possible through:

• filling up the tcache (I used 0xf0 tcache)

• freeing another one

Problem with this is...

1. It leaves an unwanted unsorted/small bin chunk we'll need to completely serve out to stop allocations earlier on in the heap

2. It wastes a lot of space on the heap as all these old tcache chunks get disconnected from tcache. We'll need to refill these phantom freed account blocks before we move on

3. We can't have too many accounts, it'll overwrite important things on the stack and maybe even the return address to account addresses(since NX is on this isn't at all helpful)

I went smart about this, and in my filling up of the heap so that we can get a nice "clean slate" ready for the second poisoning. I used comment sizes that imitated account creations.

Eventually, through some trial and error and thinking:

• I was able to do a good set of allocations

  • that efficiently used the list to fill up the entirety of the previous section of the heap

  • such that all new allocations are top chunk allocations.

Finally, we can:

• allocate a chunk with 0xf0 size

  • such that the comment chunk will be of size 0x100

  • it won't be in the previously destroyed tcache.

Explanation

Free hook is called on the pointer that is about to be freed before it is freed. Overwriting free hook with system means the chunk about to be freed (in this case /bin/sh as we wrote that to free hook -8) will have system called on it Allocating at free hook-8 to get free hook overwrite and also extra space for /bin/sh for system is a nice little trick i learned from a fizzbuzz writeup, which he learned from NotDeGhost's writeups.

Summarisation

1. Abuse lack of pointer clearing to leak heap pointers using expiries by allocating two, freeing two then allocation one(all without expiry initialisation)

2. Fill 0xf0 tcache, get an unsorted bin chunk this way(we can allocate chunks of arbitrary sizes via allocating accounts with specific sizes of comments)

3. Tcache poison to get a chunk at the expiry pointer of account 0

Flag

flag{michael_scott_for_president}