Thinking in ROP

So the conversation in the last class got me thinking about the wide-open nature of hacking in a ROP context. That context is:

Context of ROP:

• No WIN function (or a WIN function that needs arguments...)
• NX enabled (non-executable stack)
• Stack smashing made possible (either no canary or a leakable canary and an out of bounds write like gets or fgets with a large number of bytes possible)

In class I used the analogy of learning to make meals given a supermarket. You now have a TON of freedom compared to having parents prepare your meals.

I was asked the question, what are the basics of ROP. The truth is that the basics are maybe too abstract to help, but here goes an attempt:

Universal Basics of ROP

• You can control the stack at the moment a ret instruction is executed
• You want a shell or a flag, e.g. system("/bin/sh")

That's maybe not that helpful to a young practitioner.

In my feeding yourself analogy that's like saying, all meals involve eating food.

You need to know how to make a meal for yourself, and the truth is there are a LOT of ways to do that. We have whole cooking networks and reality shows and recipe books and subcultures of etiquitte. None of which are prerequisites to you eating.

So now the question is, how do I guide you through some interesting ways to use this skill?

Typical Requirements for a ROP Shell

• Conquering address randomization
• Knowing how to pass an argument to system (alternatively syscall)
• Identifying/Imagining interesting locations to jump to

Let's tackle these one at a time

Address Randomization

We know that there are essentially 3 (soon to be 4) valuable memory segments that are randomized every time a program executes:

• the MAIN segment (called .text)
• the STACK segment
• the GLIBC segment(s)
• (starting next week the HEAP segment)

Our analogy for these has been a fleet of battleship pieces. If you can identify any address in any of the ships you can do some simple addition/subtraction to find anything else in that segment.

Things in each of the key segments:

MAIN/.text

This segment can be unrandomized by the -no-pie flag.

This segment contains:

• The opcodes/machine-instructions for the main function and it's coder-made utilities
• The PLT symbols which are how we link to library functions
• The GOT with stored addresses to library functions which the PLT jumps to
• The .bss segment with variables that aren't the local stack variables (think one off strings like "hi" in the line printf("hi");)

The STACK

The stack sets up a "stack frame" for each function called which has room for:

• the local variables
• a canary (optional random value that tries to prevent stack tampering)
• the old base pointer
• the return address for when the function is done
• and then any stack-passed arguments after that

These frames are setup recursively so they can make a clean frame in the middle of a function call and restore the previous stack frame after a ret.

We've talked endlessly about it, but worth noting: there are always interesting little treasures (e.g. identifyable addresses from one of these key segments) to be found on the stack, so if you can scan the stack then that's good.

GLIBC segments

Inside of the glibc segments are almost anything you could ever want. I call them multiple segments because there is so much stuff that it's typically 4+ segments in a row some with R-X and some with RW-

Here are some key targets in glibc:

• system
• the string "/bin/sh"
• printf
• the "main arena" (you'll care more next week)
• libc_start_main
• Any function you'd ever code with

Possible Strategies for Randomization

OK so one of the things we need to assess is UNDER WHAT CONDITIONS can you undo randomization?

• If the problem just tells you an address then think carefully about what else is near that address
• If the problem has NO PIE then you get anything in the MAIN/.text segment including PLT/GOT/bss strings/utility functions
• In that NO PIE case you can use the PLT to show addresses from the GOT thus also derandomizing glibc
• If the server running the problem has no ASLR then you get anything in glibc and in the stack
• If there is a printf vulnerability you can read any values in the stack
• If an address near your target is baked into your problem (e.g. think they'll let you write at an offset from some address)

When we get to the heap we'll show more sophisticated ways to generate leaks that don't feel as toy-like.

Loading "/bin/sh" into system

So if you're in the wilderness you need to find a copy of "/bin/sh" somewhere

You can either write it to an address you can predict or find it in the binary or leak a glibc address.

But even given the address where "/bin/sh" lives how do you get it INTO the call of system?

• If it's 32-bit then just pop it onto the stack like this: "PADDINGHERE"+p32(systemaddr)+"JUNK"+p32(BINSHADDR)
• Note that I am presuming that the systemaddr is a jmp to the PLT or jmp to glibc system, IF INSTEAD you are jumping to something like call system you don't need the "JUNK" four-byte offset (this offset is because "call" pushes a return address onto the stack which you have to emulate when JMPing rather than CALLing)
• If it's a 64-bit challenge then we need the address to be in the RDI register
• That requires a "GADGET" which is an address of two instructions: pop rdi; ret;
• You can find such a GADGET using the utility: ROPgadget --binary nameofbinary and looking for the right gadget.
• ONE LAST NOTE: before the system call the value of RSP needs to be 0 mod 16 (stack aligned) you can fix this with one other gadget: a simple ret You can find these all over the place for what it's worth

Advanced Strategies

I'd like to highlight my auto-pwn ROP chain presuming NO PIE and partial RELRO.

This is a sophisticated ROP chain that is doing the following:

• display the address of puts from glibc (generating a leak)
• let me type an address into the GOT to replace the address of puts with whatever I want (I'll write the address of SYSTEM)
• let me type a string into an address near the GOT (so I can write "/bin/sh" to a predictable address)
• jump to the address from stage 2 with the argument from stage 3 (system("/bin/sh"))
• In 32-bit there's an extra "clean up the stack" gadget which just pops the arguments into some meaningless register

Here's the 64-bit version:

Here's the 32-bit version of the same concept:

Picking interesting targets

So my favorite recipe is system("/bin/sh") so I'm hunting for any method I can to do that.

But sometimes the challenge forces you to do unusual tricks so this section might be "alternatives" to the standard system("/bin/sh") strat.

• Any WIN function... that's the first thing I want to find
• ONE GADGET! one_gadget is a cool utility that finds a single address in a glibc that pops a shell for you. Typically these have some constraints like r9 is null or rsp+27 is 0 or something weird like that.
• Editing the GOT? If you have a printf you can do a write-what-where and maybe replace a GOT library function with something cool (like a one_gadget?)
• a syscall gadget? We'll do this Friday where a syscall gadget can be used to invoke any kernel level process, the most common are execve and read/write
• How about a "main" loop? If you can JUMP back to the start of main you might benefit from multiple passes through the function learning more each time.
• Maybe mmap? If you can call mmap then you can create a RWX segment and do shellcode.

With the supermarket strategy this section is sort of a world cuisine tour, there are MANY WAYS to win and you can expand your horizons with more practice, CTFing, experimenting with new methods.

You don't have to master them all, but the more you know the better you get.