Project 1: Buffer Overflows
Due: Feb 18, 2008
Updates
- Feb 9. One more tip added below.
- Feb 5. You can assume that the exploit code is running on the
same machine as the httpd server, i.e., your exploit should always
just connect to localhost. Also, the client of the exploit will
manually type in the port number---you don't need to figure it out
from the binary or anything like that.
Description
I am a bad programmer. I'm such a bad programmer, I introduce bugs in
other people's code on purpose. I've taken a simple http server I
found on the web and introduced several potential buffer overflows in
it.
Here is the web server:
tinyhttpd-broken.tar.gz
Your job is to develop a program that exploits a buffer overflow to
take over the httpd process, causing it to print a message "Now I pwn
your computer":
(machine 1) host2$ ./httpd
http running on port 42709
...
Now I pwn your computer
(machine 2) host1$ ./exploit httpd 42709
Here ... can be empty, or may be some additional output
caused by your attack. Your exploit file takes the httpd
file as input (at your discretion; if you change this, be sure to
mention it in your instructions). Your exploit must work on
fireball.cs.umd.edu, when I compile httpd with gcc 3.2.3.
Tips:
- Be sure to test your exploit on the machine configuration
specified above. Newer versions of gcc include default protections
against some buffer overflows. (E.g., on newer versions of gcc, you
may need to compile -fnostack-protector.)
- To get your exploit working reliably, you may also need to disable
executable stack protection. Use the command execstack -s
httpd to indicate the httpd executable must be run with
an executable stack. You will get extra credit if your exploit works
without needing this.
- You may also need to disable address
space layout randomization. You should be able to do this by
running httpd with the command setarch i386 ./httpd
(this should also disable executable stack protection). Turning on
the executable stack flag, as described above, may also disable
address space randomization, but I'm not sure. You will get extra
credit if your exploit works without needing to disable address space
layout randomization.
- Since I've told you that I modified the program to introduce a
buffer overflow, you can probably figure out what I did with a
combination of Google and diff. However, it's really not too hard to
figure out where the problem is, so try to do it by just looking at
the code.
- The above tweaks do not prevent the initial stack location from
being changed each time httpd is run. Here are some ideas
for dealing with this:
- Insert a "landing pad" before your real code so that you don't
need to get the exact target address to jump to correct. A landing
pad is just a long sequence of nop instructions, so that no matter
where eip lands in that string, it will progress to the first "real"
instruction.
- As a temporary hack, modify httpd to print out its
starting stack address, and develop your exploit code based on that.
(So add another input to exploit.) Then, come back and see if
you can deal with the stack space layout change.
Project Submission Instructions
- Write the program exploit. You can assume you have
access to the httpd executable (the name of which is passed
on the command-line to your program). Your program should work on the
stated platform.
- In a single file (e.g., tar.gz or zip), submit your program to me
via email, along with any anciliary tools you use to generate
parameters and constants. Include in your submission full
instructions for running your program. You will get the most credit
for writing the most-automated exploit generator, but you will still
get lots of credit for writing an exploit program that needs
to be tweaked by hand some, as long as you explain the necessary
tweaks clearly and I can easily follow your instructions. I will
grade your project by compiling httpd and trying your exploit
on it.
- In your email to me, include a brief description of the cause of
the buffer overflow(s) and how to fix it.
- If it turns out that there are buffer overflows in the software,
but they are not exploitable, rather than writing a program
exploit, write a detailed explanation of why an exploit is
not possible.
Resources
Acknowledgements
Inspired by a similar project from
Steve Zdancewic.