The Attack Lab: Understanding Buffer-Overflow Bugs

Introduction

This assignment involves generating a total of five attacks on two programs having different security vulnerabilities.

Outcomes you will gain from this lab include:

• You will learn different ways that attackers can exploit security vulnerabilities when programs do not safeguard themselves well enough against buffer overflows.
• Through this, you will get a better understanding of how to write programs that are more secure, as well as some of the features provided by compilers and operating systems to make programs less vulnerable.
• You will gain a deeper understanding of the stack and parameter-passing mechanisms of x86-64 machine code.
• You will gain a deeper understanding of how x86-64 instructions are encoded.
• You will gain more experience with debugging tools such as gdb and objdump.

You will want to study Sections 3.10.3, Out-of-Bounds Memory References and Buffer Overflow, and 3.10.4, Thwarting Buffer Overflow Attacks of Bryant & O’Hallaron's Computer Systems (3rd edition) textbook as reference material for this lab.

Logistics

As usual, you should work with your lab partner(s). You will generate attacks for target programs that are custom-generated for you.

Getting Files

See the instructions on the course website for getting your team's target.

The server will build your files and return them to your browser in a tar file called targetk.tar, where k is the unique number of your target programs.

After saving the targetk.tar file in a (protected) directory on wilkes in which you plan to do your work, give the command: tar -xvf targetk.tar. This will extract a directory targetk containing the files described below.

You should only download one set of files. If for some reason you download multiple targets, choose one target to work on and delete the rest.

Warning: If you expand your targetk.tar on a PC by using a utility such as Winzip or letting your browser do the extraction, you'll risk resetting permission bits on the executable files.

The files in targetk include:

README.txt

A file describing the contents of the directory.

ctarget

An executable program vulnerable to code-injection attacks.

rtarget

An executable program vulnerable to return-oriented programming attacks.

cookie.txt

An 8-digit hex code that you will use as a unique identifier in your attacks.

farm.c

The source code of your target's “gadget farm”, which you will use in generating return-oriented programming attacks.

hex2raw

A utility to generate attack strings.

In the following instructions, we will assume that you have copied the files to a protected directory on wilkes, and that you are executing the programs in that directory.

Hand-in

As in the Bomb lab, there is no explicit hand-in. The target will notify us automatically about your progress as you work on it. You can keep track of how you are doing by looking at the class scoreboard at:

\url{https://www.cs.hmc.edu/cs105/attack/scoreboard}\\


This web page is frequently updated to show the progress for each team's targets.
Note that the web page does \emph{not} update every time you refresh it.

Target Programs

Both ctarget and rtarget read strings from standard input. They do so with the function getbuf:

unsigned getbuf()
{
    char buf[BUFFER_SIZE];
    Gets(buf);
    return 1;
}

The function Gets is similar to the standard library function gets—it reads a string from standard input (terminated by \n or end-of-file) and stores it (along with a null terminator) at the specified destination. In this code, you can see that the destination is an array buf, declared as having BUFFER_SIZE bytes. At the time your targets were generated, BUFFER_SIZE was a compile-time constant specific to your version.

The functions Gets() and gets()have no way to determine whether their destination buffers are large enough to store the string they read. They simply copy sequences of bytes, possibly overrunning the bounds of the storage allocated at the destination.

If the string typed by the user and read by getbuf is sufficiently short, it is clear that getbuf will return 1, as shown by the following execution examples:

./ctarget
Cookie: 0x1a7dd803
Type string:Keep it short!
No exploit.  Getbuf returned 0x1
Normal return

(Note that the value of the cookie shown will differ from yours.)

Typically an error occurs if you type a long string:

./ctarget
Cookie: 0x1a7dd803
Type string:This is not a very interesting string, but it has the property ...
Ouch!: You caused a segmentation fault!
Better luck next time

Program rtarget will have the same behavior. As the error message indicates, overrunning the buffer typically causes the program state to be corrupted, leading to a memory-access error. Your task is to be more clever with the strings you feed ctarget and rtarget so that they do more interesting things. The strings that cause such behavior are called exploit strings.

Both ctarget and rtarget take several different command-line arguments:

-h

Print a list of possible command-line arguments

-q

Don't send results to the grading server

-i FILE

Supply input from a file, rather than from standard input

Your exploit strings will typically contain byte values that do not correspond to the ASCII values for printing characters. The program hex2raw will enable you to generate these raw strings. More information on how to use hex2raw.

Important points:

• Your exploit string must not contain byte value 0x0a at any intermediate position, since that is the ASCII code for newline (“\n'). WhenGets` encounters this byte, it will assume you intended to terminate the string.

• hex2raw expects two-digit hex values separated by one or more white spaces.

  So if you want to create a byte with a hex value of 0, you need to write it as 00. To create the word 0xdeadbeef you should pass “ef be ad de” to hex2raw (note the reversal required for little-endian byte ordering).

• Appendix A also contains examples of using I/O redirection (< and >) and pipes (|) on the command line, as used in the example below.

When you have correctly solved one of the levels, your target program will automatically send a notification to the grading server. For example:

./hex2raw < ctarget.l2.txt | ./ctarget
Cookie: 0x1a7dd803
Type string:Touch2!: You called touch2(0x1a7dd803)
Valid solution for level 2 with target ctarget
PASSED: Sent exploit string to server to be validated.
NICE JOB!

The server will test your exploit string to make sure it really works, and it will update the Attacklab scoreboard page indicating that your user id (listed by your target number for anonymity) has completed this phase.

Unlike the Bomb Lab, there is no penalty for making mistakes in this lab. Feel free to fire away at ctarget and rtarget with any strings you like.

Figure \ref{fig:phases} summarizes the five phases of the lab. As can be seen, the first three involve code-injection (CI) attacks on ctarget, while the last two involve return-oriented-programming (ROP) attacks on rtarget. Note that the fifth phase is extra-credit.

Part I: Code-Injection Attacks

For the first three phases, your exploit strings will attack ctarget. This program is set up so that the stack positions will be consistent from one run to the next and so that data on the stack can be treated as executable code. These features make the program vulnerable to attacks where the exploit strings contain byte encodings of executable code.

Level 1

For Phase 1, you will not inject new code. Instead, your exploit string will redirect the program to execute an existing procedure.

Function getbuf is called within ctarget by a function test, which has the following C code:

void test()
{
    int val;
    val = getbuf(); 
    printf("No exploit.  Getbuf returned 0x%x\n", val);
}

When getbuf executes its return statement (line 5 of getbuf), the program ordinarily resumes execution within function test (at line 5 of this function). We want to change this behavior. Within the file ctarget, there is code for a function touch1 having the following C representation:

void touch1()
{
    vlevel = 1;       /* Part of validation protocol */
    printf("Touch1!: You called touch1()\n");
    validate(1);
    exit(0);
}

Your task is to get ctarget to execute the code for touch1 when getbuf executes its return statement, rather than returning to test. Note that your exploit string may also corrupt parts of the stack not directly related to this stage, but that will not cause a problem, since touch1 causes the program to exit directly.

Some Advice:

• All the information you need to devise your exploit string for this level can be determined by examining a disassembled version of ctarget. Use objdump -d to get this disassembled version.

• The idea is to position a byte representation of the starting address for touch1 so that the ret instruction at the end of the code for getbuf will transfer control to touch1.

• Be careful about byte ordering, and remember that addresses are 8 bytes.

• You might want to use gdb to step the program through the last few instructions of getbuf to make sure it is doing the right thing.

• The placement of buf within the stack frame for getbuf depends on the value of the compile-time constant BUFFER_SIZE and on the allocation strategy used by gcc. You will need to examine the disassembled code to determine its position.

Level 2

Phase 2 involves injecting a small amount of code as part of your exploit string.

Within the file ctarget there is code for a function touch2 having the following C representation:

void touch2(unsigned val)
{
    vlevel = 2;       /* Part of validation protocol */
    if (val == cookie) {
    printf("Touch2!: You called touch2(0x%.8x)\n", val);
    validate(2);
    } else {
    printf("Misfire: You called touch2(0x%.8x)\n", val);
    fail(2);
    }
    exit(0);
}

Your task is to get ctarget to execute the code for touch2 rather than returning to test. In this case, however, you must make it appear to touch2 as if you have passed your cookie as its argument.

Some Advice:

• You will want to position a byte representation of the address of your injected code in such a way that ret instruction at the end of the code for getbuf will transfer control to it.

• Recall that the first argument to a function is passed in register rdi.

• Your injected code should set the register to your cookie, and then use a ret instruction to transfer control to the first instruction in touch2.

• Do not attempt to use jmp or call instructions in your exploit code. The encodings of destination addresses for these instructions are difficult to formulate. Use ret instructions for all transfers of control, even when you are not returning from a call.

• See the discussion in Appendix \ref{app:bytecode} on how to use tools to generate the byte-level representations of instruction sequences.

Level 3

Phase 3 also involves a code-injection attack, but this time requires passing a string as the argument.

Within the file ctarget there is code for functions hexmatch and touch3 having the following C representations:

/* Compare string to hex represention of unsigned value */
int hexmatch(unsigned val, char *sval)
{
    char cbuf[110];
    /* Make position of check string unpredictable */
    char *s = cbuf + random() % 100;
    sprintf(s, "%.8x", val);
    return strncmp(sval, s, 9) == 0;
}

void touch3(char *sval)
{
    vlevel = 3;       /* Part of validation protocol */
    if (hexmatch(cookie, sval)) {
    printf("Touch3!: You called touch3(\"%s\")\n", sval);
    validate(3);
    } else {
    printf("Misfire: You called touch3(\"%s\")\n", sval);
    fail(3);
    }
    exit(0);
}

Your task is to get ctarget to execute the code for touch3 rather than returning to test. You must make it appear to touch3 as if you have passed a string representation of your cookie as its argument.

Some Advice:

• You will need to include a string representation of your cookie in your exploit string. The string should consist of the eight hexadecimal digits (ordered from most to least significant) without a leading “0x.”

• Recall that a string is represented in C as a sequence of bytes followed by a byte with value 0. Type “man ascii” on any Linux machine to see the byte representations of the characters you need.

• Your injected code should set register reg to the address of this string.

• When the functions hexmatch and strncmp are called, they push data onto the stack, overwriting portions of the memory that held the buffer used by getbuf. As a result, you will need to be careful where you place the string representation of your cookie.

• hexmatch is a bit difficult to understand. In essence, hexmatch(val, sval) converts val into printable hexadecimal format and compares it with the 8-character string sval, returning true if the two match. So, for example:

  • hexmatch(0x1234abcd, "1234abcd") returns true
  • hexmatch(0x1, "00000001") returns true
  • hexmatch(0xdcba4321, "1234abcd") returns false, and
  • hexmatch(0x1234ABCD, "1234ABCD") returns false (why?).

Part II: 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:

• It uses randomization so that the stack positions differ from one run to another. This makes it impossible to determine where your injected code will be located.
• It marks the section of memory holding the stack 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.

Fortunately, 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) \cite{roemer-2012,schwartz-2011}. The strategy with ROP is to identify byte sequences within an existing program that consist of one or more instructions followed by the instruction ret. Such a segment is referred to as a gadget. Figure \ref{fig:rop} illustrates how the stack can be set up to execute a sequence of n gadgets. In this figure, the stack contains a sequence of gadget addresses. Each gadget consists of a series of instruction bytes, with the final one being 0xc3, encoding the ret instruction. 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 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. Fortunately, 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

The byte sequence 48 89 c7 encodes the instruction movq rax, rdi (See Figure for the encodings of useful movq instructions.) This sequence is followed by byte value c3, which encodes the ret instruction. 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 and which will copy the 64-bit value in register rax to register rdi.

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. Your job will be to identify useful gadgets in the gadget farm and use them to perform attacks similar to those you did in Phases 2 and 3.

Important: The gadget farm is demarcated by functions start_farm and end_farm in your copy of rtarget. Do not attempt to construct gadgets from other portions of the program code.

(When logged in, completion status appears here.)