Return-Oriented Programming

Performing code-injection attacks on the program rtarget is much more difficult than it is for ctarget, because it uses two techniques to thwart such attacks:

• Randomization The stack positions differ from one run to another. This defense makes it impossible for you to determine where your injected code will be located in memory.
• Nonexecutable Memory The memory holding the stack is marked as nonexecutable, so even if you could set the program counter to the start of your injected code, the program would fail with a segmentation fault.

Return-Oriented Programming

Fortunately (for doing this lab), clever people have devised strategies for getting useful things done in a program by executing existing code, rather than injecting new code. The most general form of this approach is referred to as return-oriented programming (ROP).

The ROP strategy is to identify byte sequences within an existing program that consist of one or more instructions followed by the ret instruction. Such a segment is referred to as a gadget.

The following figure illustrates how the stack can be set up to execute a sequence of \( n \) gadgets:

The stack contains a sequence of gadget addresses. Each gadget consists of a series of instruction bytes, with 0xc3 (the ret instruction) as the final byte of the gadget. When the program executes a ret instruction starting with this configuration, it will initiate a chain of gadget executions, with the ret instruction at the end of each gadget causing the program to jump to the beginning of the next.

A gadget can make use of code corresponding to assembly-language statements generated by the compiler, especially ones at the ends of functions. In practice, there may be some useful gadgets of this form, but usually not enough to implement many important operations. For example, it is highly unlikely that a compiled function would have popq reg as its last instruction before ret. But with a byte-oriented instruction set such as x86-64, a gadget can often be found by extracting patterns from other parts of the instruction byte sequence.

For example, one version of rtarget contains code generated for the following C function:

void setval_210(unsigned *p)
{
    *p = 3347663060U;
}

The chances of this function being useful for attacking a system seem pretty slim. But, the disassembled machine code for this function shows an interesting byte sequence:

0000000000400f15 <setval_210>:
  400f15:   c7 07 d4 48 89 c7       movl   $0xc78948d4,(%rdi)
  400f1b:   c3                      retq

Ignoring the first three bytes at address 0x400f15, we have the byte sequence 48 89 c7, which encodes the instruction movq rax, rdi.

Our cherry-picked sequence is followed by byte value c3, which encodes the ret instruction. So the function starts at address 0x400f15, and the sequence starts on the fourth byte of the function. Thus this code contains a gadget that has a starting address of 0x400f18 that copies the 64-bit value in register rax to register rdi.

The Gadget Farm

Your code for rtarget contains a number of functions similar to the setval_210 function shown above. They all reside in a region we refer to as the gadget farm.

Steps

• Phase 4: Calling touch2 with Gadgets
• Phase 5: Calling touch3 with Gadgets and a String Argument (optional)

Instruction Tables

(When logged in, completion status appears here.)