Next, download and decompress
sandbox-3.0.ova.zip from the Blackboard course site.
Launch VirtualBox and select the menu option
File > Import Appliance. Choose the
sandbox 3.0.ova file you just decompressed.
Once you start the virtual machine, Linux will boot and you’ll be presented with a login prompt. The default account has a user name of
user and a password of
You will need to configure Git inside the VM.
$ git config --global user.name "Your name here" $ git config --global user.email "Your email here"
You’re now ready to clone the assignment repository.
The VM has a number of tools installed including the
gcc compiler and
gdb debugger. It has
vim installed. If you want to install additional tools such as other text editors, you may install them. E.g.,
$ sudo apt install emacs
The password is
Go to the GitHub Classroom page and accept the assignment.
Warning: Do not join any team other than your partner’s. There’s no way to change teams for the assignment so just don’t do it! (If you do join the wrong team by mistake, let me know immediately.)
You should now be able to clone the assignment repository in your VM.
Once you have cloned your assignment repository in the VM, you need to enter your name and your partner’s name in the
ID file. If you’re working with a partner, one of you should edit the
ID file, commit it, and push it to GitHub. The other partner should
git pull the change.
After you have done this, run
to generate the
WARNING: Once you have generated the
targets directory, any changes to your
ID file at all will cause the
generate_targets.py script to generate different targets and your exploits will likely not work when we’re grading.
targets directory contains the source code for the targets along with a
Makefile specifying how they are to be built. To compile the targets and install them setuid root in
/tmp, use the commands
make install. You will need to enter the password
pass at the prompt when you run
target5 is fairly complicated. It reads commands for manipulating strings from the file specified as its argument. Due to the way
target5 is compiled, the glibc
realloc functions are not used. Instead, the replacement functions in
smalloc.c are called. It is easiest to set a breakpoint in
srealloc rather than trying to step into calls to
Do not commit the
targets directory. For grading, we will run the
generate_targets.py script and run your exploits against those targets.
sploits directory in the assignment contains skeleton source for the exploits which you are to write, along with a
Makefile for building them. Also included is
shellcode.h, which contains shellcode for you to use.
Your exploits should assume that the compiled target programs are installed in
Along with each exploit skeleton file, there is an empty text file that you should fill with an explanation of the bug in the corresponding target and how your exploit takes advantage of it. You will submit this explanation along with your exploit.
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 (
README.md. You will want to have a good understanding of what happens to the stack, program counter, and relevant registers before and after a function call. Read scut’s “Exploiting Format String Vulnerabilities.” It will be helpful to have a solid understanding of the basic buffer overflow exploits before reading the more advanced exploit papers.
nexticommands. You may find the
xcommand useful to examine memory (and the different ways you can print the contents such as
info registercommand is helpful for printing out the contents of registers.
A useful way to run GDB is to use the
-s command line flags; for example, the command
gdb -e ./sploit3 -s /tmp/target3
tells GDB to execute
sploit3 and use the symbols from
target3 which allows you to trace execution in the target in exactly the way it is executed by the exploit. By contrast, executing just
gdb /tmp/target3 will trace the target in the way it is executed by the shell, so the memory layout will be different. (Avoiding a segfault while using this requires careful timing in setting breakpoints. See the assignment
README.md for the details.)
malloc). Try placing the shellcode somewhere else.
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 be changed based on how the exploit is executed (working directory, arguments, environment, etc.); in our testing, we do not guarantee to execute your exploits the same way
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.
sploit2.txt, and so on). In this text file, explain how your exploit works: what the bug is in the corresponding target, how you exploit it, and where the various constants in your exploit come from.
IDwhich contains the names of all partners (or just your own if you worked by yourself). Heed the warning about changing