Project (Attack Lab)

Out: Nov 4.
Due: Nov 19, 11:59pm (25% per day late, as with most of the other course deadlines).

Goal

The goal of this assignment is to give you some hands-on experience with the effect of buffer overflow, format string, and double free bugs. All work in this project must be done on a system called boxes (implemented using User-Mode Linux); see below for how to obtain boxes.
You are given the source code for seven exploitable programs (/tmp/target1, ... , /tmp/target7). These programs are all installed as setuid root in the boxes system. Your goal is to write seven exploit programs (sploit1, ..., sploit7). Program sploit[i] will execute program /tmp/target[i], giving it certain input that should result in a root shell on the boxes system.
The skeletons for sploit1, ..., sploit7 are provided in the sploits/ directory. Note that the exploit programs are very short, so there is no need to write a lot of code here.

The Environment

You will test your exploit programs within a system called Boxes. Boxes, based on User-Mode Linux, allows you to boot a fully-functional Linux system as a userland process on another Linux machine.
Boxes is available from the course website. It should run on x86 GNU/Linux machines running a recent 2.4- or 2.6-series kernel. You must install Boxes on a GNU/Linux machine on your own. Please refer to the README file in the Boxes distribution.
It is recommended that you test your exploits in a virtual machine booted with a "closedbox" kernel, so that you cannot accidentally damage your host account.
It is recommended that you develop your code on the host machine, or at least keep frequent backups. The User-Mode Linux kernel is mostly stable, but can occasionally crash.
The last section of this handout runs you through setting up the environment on some machines at UW.

The Targets

The targets/ directory in the assignment tarball contains the source code for the targets, along with a Makefile specifying how they are to be built.
Your exploits should assume that the compiled target programs are installed setuid-root in /tmp -- /tmp/target1, /tmp/target2, etc.

The Exploits

The sploits/ directory in the assignment tarball contains skeleton source for the exploits which you are to write, along with a Makefile for building them. Also included is shellcode.h, which gives Aleph One's shellcode.

The Assignment

You are to write exploits, one per target. Each exploit, when run in the Boxes environment with its target installed setuid-root in /tmp, should yield a root shell (/bin/sh).

Hints

Read Aleph One's Smashing the Stack for Fun and Profit." Also look at these two papers: blended attacks and format string vulnerabilities. These readings will help you develop a good understanding of what happens to the stack, program counter, and relevant registers before and after a function call, but you may wish to experiment as well. It will be helpful to have a solid understanding of the basic buffer overflow exploits before reading the more advanced exploits.
gdb will likely prove very useful. Specifically, note the "disassemble" and "stepi" commands. You may find the "x" command useful to examine memory (and the different ways you can print the contents such as "/a /i" after "x"). The "info register" command is helpful in printing out the contents of registers such as ebp and esp. A useful command to run gdb is to use the "-e" and "-s" command line flags; for example, the command "gdb -e sploit3 -s /tmp/target3" in boxes tells gdb to execute sploit3 and use the symbol file in target3. These flags let you trace the execution of the target3 after the sploit has forked off the execve process. When running gdb using these command line flags, be sure to "run" the program before you set any breakpoints; for our purposes, entering the command "run" naturally breaks the execution at the first SIGTRACE before the target is actually exec-ed, so you can set your breakpoints when gdb catches the SIGTRACE. If you wish, you can instrument your code with arbitrary assembly using the asm () pseudofunction.
Make sure that your exploits work within the Boxes environment (and specifically the closedbox).
Start early. Theoretical knowledge of exploits does not readily translate into the ability to write working exploits. Target1 is relatively simple and the other problems are quite a bit more complicated.

Warnings

Aleph One gives code that calculates addresses on the target's stack based on addresses on the exploit's stack. Addresses on the exploit's stack can change based on how the exploit is executed (working directory, arguments, environment, etc.); in our testing, we do not guarantee to execute your exploits as bash does.

You must therefore hard-code target stack locations in your exploits. You should not use a function such as get_sp() in the exploits you hand in.

Deliverables

You may work in groups of up to three people.
You are to provide a tarball (i.e., a .tar.gz file) containing the source files and Makefile for building your exploits. All the exploits should build if the "make" command is issued.
There should be no directory structure: all files in the tarball should be in its root directory. (Run tar from inside the sploits/ directory.)
Along with your exploits, you must include file called "ID" which contains the name of everyone in your group. (You only need one submission per group.)
Again, make sure that you test your exploits within the Boxes environment.
Turn in your .tar.gz files online using the Catalyst system.

How to set up the Environment

Here are the following steps to set up the environment on the Linux machines in the deparment; the cycle servers bicycle, tricycle, and recycle are recommended if you do not have a desktop Linux machine. You may also use the machine named Storm in the security lab.

Log into the lab machine of your choice.
cd into /tmp, create a directory for yourself.
Make sure that no one else can read your directory in /tmp by setting the permissions, e.g., "chmod 700 /tmp/yoshi".
Get Boxes and the programming project.
wget http://www.cs.washington.edu/education/courses/cse564/08au/project-20081103.tar.bz2
wget http://www.cs.washington.edu/education/courses/cse564/08au/boxes-20071104.tar.bz2
Extract these files
romieu% tar jxvf boxes-20071104.tar.bz2 ; tar xjvf project-20081103.tar.bz2
Since we extracted the files into /tmp/yoshi, we need to set up the Boxes enviroment variables as follows (assuming you're using the tcsh shell):
romieu% setenv BOXESDIR /tmp/yoshi/boxes
romieu% setenv BOXESHOME /tmp/yoshi
romieu% setenv PATH /tmp/yoshi/boxes:$PATH
For convenience, instead of repeatedly typing in the commands, you may wish to place the three setenv commands into a file and "source" the file whenever you log into a machine.
Now we want to start openboxes with a virtual network. Don't forget that we're testing on a closedbox so you want to test your exploits on that before submitting. The difference between an open and closed box is that you can't mount the hostfs in a closed box and you can't ssh into a closed box. Start the switch daemon (behaves like a network switch).
romieu% xterm -e boxes/string &
Then run boxes, specifying the copy-on-write disk and the virtual private network.
romieu% boxes/openbox cow1 10.64.64.64
There are two accounts on these boxes, root and user. The passwords are the same as the usernames. To get your project files onto boxes, log in as root and mount the machine's local filesystem in boxes with the following command
box:~# mount none -t hostfs /mnt -o /tmp/yoshi/project
Now you can access the project files in /mnt. Copy the sploits dir to the user's home directory (and make sure to set the ownership so that user can access them "chown -R user:user sploits"), and target dir to root's home directory. Make the targets and copy the targets to /tmp together with the corresponding .c and .h files. Using the following commands, set up the permissions so that the targets are owned by root, are setuid root, and the .c and .h files are publicly readable.
box:~# chown root:root target? ; chmod 4755 target? ; chmod a+r target?.[ch] ; chmod a+r tmalloc.[ch]
Everytime you reboot boxes, you'll have to set up the targets in boxes's /tmp because it will be wiped clean. Also make sure to periodically transfer your work out to your home directory on the real machines because the lab machines' /tmp (containing your copy of boxes and the project) gets wiped periodically. To save your instance of boxes, you can copy cow1 to your home directory and then when you set boxes up again, you can just copy cow1 back to your /tmp directory and start boxes with that image.
To create more virtual terminals, while root in boxes, do
box:~# TERM=vt100 ; vi /etc/inittab
and uncomment out lines:
##2:23:respawn:/sbin/getty 38400 vc/2
##3:23:respawn:/sbin/getty 38400 vc/3
to spawn two extra console windows on the next reboot of boxes. The only two editors on the boxes environment are nano and vi. If you prefer other editors, write the code outside of boxes and then use nano to paste the code into a text file in a boxes console.
For more information, read boxes/FAQ and boxes/README.
The easiest way to transfer your work from an openbox to a closedbox is to reuse the same cow when starting up a closedbox.

Misc

There's lots of online documentation for GDB. Here's one you might start with: http://csapp.cs.cmu.edu/public/docs/gdbnotes.pdf.

Credits

This project was originally designed for Dan Boneh and John Mitchell's CS155 course at Stanford. Thanks Dan and John!