**This is an old revision of the document!**

Project 8 (Buffer Overflow)


  • Spend 3 hours average to increase your understanding of buffer overflow attacks
  • You select the project you want to work on
  • Submit a report on what you learned along with supporting evidence
  • Choose the project that will give you the best learning experience based on your background on this topic.

The Unix machines in the Pizza Lab (1057 TMCB) in the basement have ASLR turned off for the next few weeks, so you can complete your projects on those machines. Other machines could have protections turned on that will prevent your experiments from working.

For tips on how to use GDB, here is a document detailing some of the more useful and important commands. Ignore the comments on the Bomb lab: it may become a lab later in the semester but you don't have to worry about it now.

Option 1

This option is intended for students with little or no experience using the debugger, understanding how to examine and update memory locations using a debugger, and have no experience with how the runtime stack is organized. A helpful way to start is to watch an introductory video on buffer overflow attacks. The following file makes a series of function calls main → freshman → sophomore → junior → senior. Compile the program and run it in the debugger, breaking somewhere in function senior. Print out all the stack activation frames, and label as many memory locations as you can. You should be able to identify 1) return addresses, 2) saved frame pointers (ebp), 3) local variables, 4) function arguments. You may print out a hard copy, write on it to label all the items, and turn in the hard copy. You may also submit your result electronically.

Option 2

The most recent CS 360 course now includes a project on buffer overflow attacks. This is based on a lab developed at Syracuse. You may complete that lab and submit the result for Project 8.

Option 3

I used a collection of files based on materials found in Jon Erickson's The Art of Exploitation. Visit the following page for hints on using gdb and perl, and then try a range of options to change to flow control for a program. Your deliverable is a writeup to describe what you learned.

  • Inject shell code on the stack
  • First inject your shellcode as an environment variable. Then smash the stack and cause that shellcode to execute.

Option 4 (NOT AVAILABLE FALL 2014)

For this option you can practice your buffer overflow skills against the Carnegie Mellon buflab. This lab is a part of EE 324 as well. Currently we do not have a project description posted. However the one for EE 324 is here and it is the same as what you will be doing here. However please note that you cannot work in teams, despite what that spec says. For your cookie provide your NetID. This lab can only be done on CS lab machines (not SPICE machines like the spec says). You can SSH into them if you don't want to go into the labs.

Get your bomb here. See the results board here.

Option 5

Find resources on the web to help you develop your own shell code and perform a stack smashing attack with your own shellcode instead of taking existing shellcode and using it without understanding what it does.

Option 6

Choose a compiler and O/S and reverse engineer the canary-based stack protection to learn how it works. How does it compare to the canary alternatives we discuessed in class? Demonstrate how it works to detect a stack-smashing attack.

Option 7

Learn about format string vulnerabilities and demonstrate how they work.

cs-465/project-8-buffer-overflow.1415214799.txt.gz · Last modified: 2014/11/05 12:13 by cs465ta
Back to top
CC Attribution-Share Alike 4.0 International
chimeric.de = chi`s home Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0