Project #1

Checkpoint: October 15, 2013, 5pm
Final Due: October 25, 2013, 5pm

Goal

The goal of this assignment is to gain hands-on experience with the effects of buffer overflow 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 (/bin/target1, ... , /bin/target7). These programs are all installed as setuid root in the VM. Your goal is to write seven exploit programs (sploit1, ..., sploit7). Program sploit[i] will execute program /bin/target[i], giving it certain input that should result in a root shell on the VM.
The skeletons for sploits 1 through 7 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. We provide these VMs "in the cloud." That is, we'll be running these VMs on a central server, freeing you from having to set up a local instance of VMware or installing the lab.
To connect to your VM, follow the personalized directions here.
Since these VMs are accessible from the Internet, security has been beefed up a bit. There are two accounts: user and root. The user account can only be logged into with the SSH key (unless you set a password after you log in). The root account has a secure password as a backdoor in case we break something, but should normally be accessed by using sudo from the user account.
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 update first. And of course, you'll need to be root (use sudo).

The Targets

The targets and their corresponding sources are stored in /bin. You are free to study the source code of each target. DO NOT recompile the targets!
Your exploits should assume that the compiled target programs are installed in /bin. Do not move the targets. This may break things, depending on how your exploits work.
All targets are setuid-root, which means that they run as root regardless of who runs it. The one exception is when they're run under a debugger. Allowing users to debug a setuid executable is a GIANT security flaw, so setuid programs temporarily lose their setuid-ness under a debugger. This means that you can only get a root shell when your sploits are ran outside of gdb. However, if you get a user shell inside gdb, you should get a root shell outside of gdb.

The Exploits

The sploits/ directory in the user home directory contains the 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 an exploit for each target. Each exploit, when run in the virtual machine with its target installed setuid-root in /bin, should yield a root shell (/bin/sh).

Hints

Read Aleph One's "Smashing the Stack for Fun and Profit." Carefully! We also recommend reading Chien and Szor's "Blended Attacks" paper. 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. It will be helpful to have a solid understanding of the basic buffer overflow exploits before reading the more advanced exploits.
Read scut's "format strings" paper. You may also wish to read http://seclists.org/bugtraq/2000/Sep/214.
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. The 'info frame' command also tells you useful information, such as where the return EIP is saved.
A useful way to run gdb is to use the -e and -s command line flags; for example, the command gdb -e sploit3 -s /bin/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).
In a bid to get you guys to start early, sploits 1-3 are due by October 15th by 5pm.
Since we have access to your VMs, you won't need to submit any code. We will test your exploits on your VMs. However, to let us know when you're done, please submit a text file with the result of running md5sum sploit?.c in your sploits directory.
Turn in your text file online using the Catalyst system. The turn-in URL is https://catalyst.uw.edu/collectit/dropbox/kohno/28907. (Make sure you can access this site before the deadlines.)

Misc

Please try to access your VM early and let us know if you have any problems!
You may wish to back up or write your code elsewhere. We suggest using SCP or SFTP to access files on your VM. For Windows, WinSCP is a great tool. SCP and SFTP run on top of SSH, so use your SSH parameters (port, key, etc.) to connect.
There's lots of online documentation for GDB. Here's one you might start with: GDB Notes (formerly hosted at CMU)
The "crash course in x86 and gdb" slides: section_lecture.pdf

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!