Project #1

Errata:

Get the updated box here: box-updated.tar.gz

Goal

The goal of this assignment is to gain hands-on experience with the effect of buffer overflow, format string, and double free bugs. All work in this project must be done in the virtual machine that we provide to you.
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 VMware virtual machine running Debian Linux. To do this, you will need to download the virtual machine image provided on the course website as well as VMware Player from VMware's website. VMware player can run on Linux, Mac OS X (VMware Fusion), and Windows, and is freely available.
The virtual machine we provide is configured with Debian Etch. We've left the package management system installed in the image, so should you need any other packages to do your work (e.g. emacs or vim), you can install it with the command apt-get (e.g. apt-get install emacs). Make sure to run apt-get udpate first.
The virtual machine is configured to use NAT (Network Address Translation) for networking. From the virtual machine, you can type ifconfig as root to see the IP address of the virtual machine. It should be listed under the field inet addr: under eth0.
The virtual machine also has an ssh server. You can ssh into the vm (virtual machine) from your machine, using the IP address produced by ifconfig (as above) as the destination. You can use this to transfer files onto the virtual machine using scp or an sftp client like winscp. Alternatively, you can fetch files directly from the web on the vm using wget.
The last section of this page 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. THIS IS VERY IMPORTANT

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 virtual machine 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." Carefully! Also read the two optional handouts. These readings will help you have 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. Read scutā's "Exploiting Format String Vulnerabilities." All the papers are linked from the course syllabus. It will be helpful to have a solid understanding of the basic buffer overflow exploits before reading the more advanced exploits.
gdb is your best friend in this assignment, particularly to understand what's going on. 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 way to run gdb is to use the -e and -s command line flags; for example, the command gdb -e sploit3 -s /tmp/target3 in the vm 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 first issue 'catch exec' then 'run' the program before you set any breakpoints; the command 'run' naturally breaks the execution at the first execve call before the target is actually exec-ed, so you can set your breakpoints when gdb catches the execve. Note that if you try to set break points before entering the command 'run', you'll get a segmentation fault.
If you wish, you can instrument your code with arbitrary assembly using the asm () pseud- ofunction.
Make sure that your exploits work within the VM environment we provided.
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. If you do work in groups, you should be sure to all work together on all targets since the midterm and final may test you on how to attack the targets (and related concepts).
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, on a single line, the following: your student ID number; your UWnet ID; and your name, in the format last name, comma, first name. An example: $ cat ./ID 12345678 johndoe Doe, John $
If you did the project with a partner, then all of you will submit only one solution and the ID file will have two lines giving the relevant information. You may want to include a README file with comments about your experiences or suggestions for improving the assignment.
Again, make sure that you test your exploits within the vm environment.
Turn in your .tar.gz files online using the Catalyst system. The turn-in URL is https://catalysttools.washington.edu/collectit/dropbox/kohno/8487. (Make sure you can access this site before the deadlines.)

How to set up the Environment

We will be showing you how to set up the environment and solving an overflow problem in section. The problem we'll be solving is essentially identical to target1, so come to section if you want a jump start. If you want an earlier start, here are the following steps that you need to take to set up the environment.

VMware player should be installed on the lab Windows machines. If you're working on your own machine, you can download and install VMware player from http://www.vmware.com/products/player/ (for Windows and Linux) or VMware Fusion from http://www.vmware.com/download/fusion/ (for Mac OS X). Note that you can't install anything on the Linux lab machines.
Download the VMware virtual machine tarball: box-updated.tar.gz).
Decompress and unarchive the virtual machine tarball:
$ tar zxvf box.tar.gz
If you're using Windows, you can use 7-zip to extract the files (7-zip should be installed on the lab Windows machines). Next, open the file box.vmx using VMware Player. If VMware Player asks you if you moved or copied the virtual machine, say that you copied it.
Login to the virtual machine. There are two accounts, root with the password root, and user with the password user.
Ensure that networking is working by typing ifconfig and checking that the inet addr: field of eth0 has a valid IP address.
If you're using a lab Windows machine:
1. Look for eth0 and notice the IP address. It should be something like 192.168.X.Y where X and Y are two more numbers. For me the address was 192.168.142.128. I'll use these numbers through the rest of the instructions. You should now be able to ssh out of the box. Try sshing into attu.
2. Okay, now back in Windows land, press the Start button and the letter r. Type cmd. Now try to ping your VM: ping 192.168.142.128 (remember to use your IP if yours was different in step 1). The ping will likely fail. If it doesn't, then skip to the step ix.
3. In the start menu, click Control Panel -> Network and Sharing Center. On the left hand side of the window that opens, choose Adapter Settings.
4. Right click on VMWare Adapter #3 and select Enable.
5. Right click on VMWare Adapter #3 and select Properties.
6. Select TCP/IPv4 and click Properties
7. Change the IP to 192.168.142.1 (Note that if your X in step i was not 142, then you should put it instead of the 142)
8. Try pinging the VM again. If it works, go to the next step, if it doesn't, eat some cake* (or seek grief counceling) and try the instructions again. If it still doesn't work, e-mail me.
9. In the start menu, navigate to the ssh client. You should now be able to ssh into the VM with the user or root account using the IP from step i.
Download the project 1 tarball (cse484-proj1.tar.gz) onto the virtual machine. You can do this by downloading the tarball first, then using scp or an sftp client to transfer the files onto the vm. Alternatively, log in as root to the vm and type:
box:~# wget http://www.cs.washington.edu/education/courses/cse484/10wi/projects/project1/cse484-proj1.tar.gz
Decompress and unarchive the files as before:
$ tar zxvf cse484-proj1.tar.gz
Copy the sploits/ directory 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 the contents of the targets/ directory to /tmp. In /tmp, make the targets then apply the following commands to set up the permissions so that the targets are owned by root, are setuid root, and the .c files are publicly readable. Doing this correctly will allow gdb to read the source files while you are debugging.
box:/tmp# chown root:root target? ; chmod 4755 target? ; chmod a+r target?.c
Every time you reboot the vm, you'll have to set up the targets in vm's /tmp because it'll be wiped clean.

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
Section lecture: section_lecture.pdf (thanks to Karl for letting me use his old slides)
Target and solution solved in section: target0.c and sploit0.c
Set up script I used in section: setup.sh. You should never run someone else's scripts without knowing what they do. So PLEASE understand what this does before you run it. Don't forget to chmod it to +x if you plan to use it. Also, if you extend it, clean it up, or make it better, please send me the updated script!

Credits

This project was originally designed for Dan Boneh and John Mitchell's CS155 course at Stanford, and was then also extended by Hovav Shacham at UCSD. Thanks Dan, John, and Hovav!

*The cake is a lie