Project #1

Checkpoint: April 20 (updated from April 17), 2015, 5pm
Final Due: May 1, 2015, 5pm

Goal

The goal of this assignment is to gain hands-on experience with the effects of buffer overflow bugs. All of the work must be done on the machine buffer-overflow-lab.cs.washington.edu (see instructions below for connecting).
You are given the source code for seven exploitable programs (/bin/target1, ... , /bin/target7). These programs are all installed as setuid hax0red. 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 shell run with the same permissions as a hax0red user. If target[i] had setuid root then sploit[i] would result in a root shell. We don't do that in this case for obvious security reasons, so instead you get the permissions of the hax0red[i] user.
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 on a remote machine running Debian Linux hosted at the domain buffer-overflow-lab.cs.washington.edu
To connect to the machine each group must first post to the forum or send the TA (Peter) an email with 1) a username for your group and 2) rsa public key (from a key pair that you control). and 3) the names and netids of your group members. Do this only once per group. Expect some delay between sending the information and account creation, so please send this early and plan accordingly.
Please do NOT send any attachments but paste the key into the body of the message. Also, do NOT send the private key (that should remain only on trusted machines).

Here is an example of a public key:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDTKPi45wxeSezgO5JmG8HiuAQH6R3kqQTeOeTbntWxliiClrahwlnkv26PAIaQKNdRbVH1fgX9kyUfsdj5JAvvNFuxpfY+GVVZKFI5M3CuzAynIymBjqnDn6Auq+tuSl8O4osb/0L9zDeQzOxQ+ed6iVDuPPkBLoX+XyuNUyYKV46xCIHOS6ao+6CkZXhp4VTz4LUvb1s8DIUcaD8/bbigxxZH3eKRQH2arV9AqP1LoC2T3azLTkHvCrcImpjVW/pxf5+nbkRb1SSkkHFvFPdd+0us12yGOp1xBbo2kuKWSdcBgd4eiGHQsO+VWi23R92bcOh/DxRZumdMyaDBMGY/ user@localhost

Generating Key Pairs

Linux/Mac:

To generate the key-pair run the following (it is strongly suggested to use a passphrase):

ssh-keygen -t rsa -f <key_name>

To use ssh:

ssh -i <path_to_private_key> <username>@buffer-overflow-lab.cs.washington.edu

Windows:

To generate the key-pair use PuTTYgen. It comes installed with PuTTY.

1) Open PuTTYgen
2) Select the type of key as SSH-2 RSA
3) Click Generate and move the mouse around to generate entropy
4) (Optional but recommended) Enter a Passphrase + Confirmation of Passphrase
5) Click save the private key
6) Copy the text of the public key to post/email from the box at the top

To ssh (with PuTTY):

On the left side, select Connection->SSH->Auth. In this pane, browse to your private key, and then login as usual. You may want to save the session for a quicker login next time.

The Targets

The targets are stored in /bin and their corresponding sources in ~/sources/. 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.
All targets are setuid hax0red[i], which means that they run as hax0red[i] 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 security flaw, so setuid programs temporarily lose their setuid-ness under a debugger. This means that you can only get a hax0red[i] shell when your sploits are ran outside of gdb. However, if you get a user shell inside gdb, you should get a hax0red[i] shell outside of gdb.

The Exploits

The ~/sploits/ 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 on the remote machine, should yield a hax0red[i] shell (/bin/sh). To confirm this is working, run the command whoami in the shell, and you should see the hax0red[i] user.

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 () pseudo function.
Make sure that your exploits work within the remote enviornment 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).
Since we have access to your remote home directory, you won't need to submit any code. 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.
In a bid to get you to start early, sploits 1-3 are due by April 20 (updated from the 17th) by 5pm.
Turn in your text file online using the Catalyst system. The turn-in URL is https://catalyst.uw.edu/collectit/dropbox/franzi/35015. (Make sure you can access this site before the deadlines.)

Misc

Please try to access the remote machine early and let us know if you have any problems! Send us a reminder email if you don't have access within 24 hours of sending your public key.
You may wish to back up or write your code elsewhere. We suggest using SCP or SFTP to access your files. 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!