Checkpoint: April 20 (updated from April 17), 2015, 5pm
Final Due: May 1, 2015, 5pm
- 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
(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.
- You will test your exploit programs on a remote machine
running Debian Linux hosted at the domain
- 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
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
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 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 ~/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
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.
- 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
- 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
- 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
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.
- 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
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.)
- 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
GDB Notes (formerly hosted at CMU)
- The "crash course in x86 and gdb" slides: section_lecture.pdf
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!