Project #1
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 three exploit programs (sploit1,
sploit4, sploit7). Program sploit[i] will execute program /bin/target[i],
giving it certain input that should result in a root shell on the boxes
system.
- 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 udpate 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 exploits for targets 1, 4, and 7. Each exploit, when run in the
virtual machine with its target installed setuid-root in /bin, should
yield a root shell (/bin/sh).
Since you saw how to do sploit 1 in class, we've changed the buffer size slightly
so that you'll have to work through it yourself. However, what was shown as target 1
in class is now target 0. If you are having trouble, you can work through sploit 0
and compare the numbers you get with those in class.
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.
- This project will not cover format string vulnerabilities, but if
you're interested in learning more about them, 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
- This project must be completed on your own.
- 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://catalysttools.washington.edu/collectit/dropbox/kohno/9908.
(Make sure you can access this site before the deadlines.)
Misc
- This is the first quarter we've tried hosting VMs for students. 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!
*The cake is a lie