Lab Assignment 3: The Attack Bomb

DUE DATES:

For the “trivia” assignment: 11:59pm, Monday, October 5. 

For the main assignment: 11:59pm, Monday, October 12. 

If you want to use slip days you have to tell us before the deadline by emailing Shuang Zhai. 

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:

Note: In this lab, you will gain firsthand experience with methods used to exploit security weaknesses in operating systems and network servers.  Our purpose is to help you learn about the runtime operation of programs and to understand the nature of these security weaknesses so that you can avoid them when you write system code.  We do not condone the use of any other form of attack to gain unauthorized access to any system resources.

Logistics

Getting Files

In a manner similar to assignment 2, each group can obtain theie files from

      http://cycle3.csug.rochester.edu:15513
    

which is only accessible on the csug network.

Since you are accessing the csug machines remotely, one way to access the webpage is to ssh into any of the CSUG cycle machines and use a text-based browser such as lynx.

On the command line, run "lynx <url>" to open the specified URL in the web browser. For instance, to request the bomb, you will type: "lynx http://cycle3.csug.rochester.edu:15513". Hit enter and the corresponding page will be loaded. Fill in your netID and email address in the corresponding fields. You can use the arrow keys to move your cursor around. Move your cursor to "submit". Press "enter/return" and the browser will prompt you to download targetk.tar. Accept the download by pressing "D". In the download options, select "Save to disk" and then press enter again when prompted to enter the filename. Press 'Q' twice to exit lynx.

Fill out the HTML form with the email address and NetID of just one of the team members, and then submit the form by clicking the “Submit” button.  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. 

Save the targetk.tar file to a (protected) directory in which you plan to do your work.  Then use the command: tar -xvf targetk.tar.  This will create a directory called targetk with the following files: 

Important Points

Here is a summary of some important rules regarding valid solutions for this lab.  These points will not make much sense when you read this document for the first time.  They are presented here as a central reference of rules once you get started.

Target Program

Both CTARGET and RTARGET read strings from standard input.  They do so with the function getbuf defined below:

      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, 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 of the programs.

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 destinations.

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 example:

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

Typically an error occurs if you type a long string:

      unix> ./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
    

(Note that the value of the cookie shown will differ from yours.) 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.  These are called exploit strings.

Both CTARGET and RTARGET take several different command line arguments:

–h
Print list of possible command line arguments.
–q
Don’t send results to the grading server.
–n 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.  See Appendix A for more information on how to use HEX2RAW.

Important points:

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

      unix> ./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 userid (listed by your target number for anonymity) has completed this phase.

You can view the scoreboard by pointing your Web browser at

      http://cycle3.csug.rochester.edu:15513/scoreboard
    

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.

IMPORTANT NOTE: You can work on your solution on any Linux machine, but in order to submit your solution, you will need to be running on one of the following machines:

cycle[1-3].csug.rochester.edu

Figure 1 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.

Phases
Figure 1: Summary of attack lab phases

Attacks

Attacks may be done in any order.

“Trivia” Assignment

Before midnight, Monday, October 5, submit answers on blackboard to the following questions.

  1. What is the very first instruction executed at the beginning of most x86 functions? What is its purpose?
  2. Where is the return address of a calling function stored relative to the stack pointer when entering the callee function?
  3. Where is the return value of a function stored when control returns to the calling function?

Appendix A Using HEX2RAW

HEX2RAW takes as input a hex-formatted string. In this format, each byte value is represented by two hex digits. For example, the string “012345” could be entered in hex format as “30 31 32 33 34 35 00”. (Recall that the ASCII code for decimal digit x is 0x3x, and that the end of a string is indicated by a null byte.)

The hex characters you pass to HEX2RAW should be separated by whitespace (blanks or newlines). We recommend separating different parts of your exploit string with newlines while you’re working on it. HEX2RAW supports C-style block comments, so you can mark off sections of your exploit string. For example:

      48 c7 c1 f0 11 40 00 /* mov    $0x40011f0,%rcx */
    

Be sure to leave space around both the starting and ending comment strings (“/*”, “*/”), so that the comments will be properly ignored.

If you generate a hex-formatted exploit string in the file exploit.txt, you can apply the raw string to CTARGET or RTARGET in several different ways:

  1. You can set up a series of pipes to pass the string through HEX2RAW.
  2. You can store the raw string in a file and use I/O redirection:
              unix> ./hex2raw < exploit.txt > exploit-raw.txt
              unix> ./ctarget < exploit-raw.txt
            
    This approach can also be used when running from within GDB:
              unix> gdb ctarget
              (gdb) run < exploit-raw.txt
            
  3. You can store the raw string in a file and provide the file name as a command-line argument:
              unix> ./hex2raw < exploit.txt > exploit-raw.txt
              unix> ./ctarget -i exploit-raw.txt
            
    This approach can also be used when running from within GDB.

Appendix B Generating Byte Codes

Using GCC as an assembler and OBJDUMP as a disassembler makes it convenient to generate the byte codes for instruction sequences. For example, suppose you write a file example.s containing the following assembly code:

      # Example of hand-generated assembly code
              pushq   $0xabcdef          # Push value onto stack
              addq    $17,%rax           # Add 17 to %rax
              movl    %eax,%edx          # Copy lower 32 bits to %edx
    

The code can contain a mixture of instructions and data. Anything to the right of a ‘#’ character is a comment.

You can now assemble and disassemble this file:

      unix> gcc -c example.s
      unix> objdump -d example.o > example.d
    

The generated file example.d contains the following:

      example.o: file format elf64-x86-64


      Disassembly of section .text:

      0000000000000000 <.text>:
         0: 68 ef cd ab 00        pushq  $0xabcdef
         5: 48 83 c0 11           add    $0x11,%rax
         9: 89 c2                 mov    %eax,%edx
    

The lines at the bottom show the machine code generated from the assembly language instructions. Each line has a hexadecimal number on the left indicating the instruction’s starting address (starting with 0), while the hex digits after the ‘:’ character indicate the byte codes for the instruction. Thus, we can see that the instruction push $0xABCDEF has hex-formatted byte code 68 ef cd ab 00.

From this file, you can get the byte sequence for the code:

      68 ef cd ab 00 48 83 c0 11 89 c2
    

This string can then be passed through HEX2RAW to generate an input string for the target programs. Alternatively, you can edit example.d to omit extraneous values and to contain C-style comments for readability, yielding:

      68 ef cd ab 00   /* pushq $0xabcdef */
      48 83 c0 11      /* add $0x11,%rax */
      89 c2            /* mov %eax,%edx */
    

This is also a valid input you can pass through HEX2RAW before sending to one of the target programs.

Turn-In

There is no explicit turn-in.  You can keep track of how you (and the other groups) are doing by looking at http://cycle3.csug.rochester.edu:15513/scoreboard .

This web page is updated continuously to show the progress of each group.