Lab 3 - Hacking a buffer bomb

Resources

• Lab 3 handout, in Postscript and Adobe Acrobat.
• All files are in the directory /afs.cs.cmu.edu/academic/class/15213-f01/L3
• A Web page showing the status of all successful submissions

Additional Information

• Oct. 3
  • Be careful which value you put on the stack as the saved value of %ebp. In particular, make sure it is the value stored on the stack at the address held in register %ebp, rather than the value of %ebp itself.
  • To get your exploit code to return to the correct place in test, you can either 1) attempt a direct jmp to the address, or 2) push the address with pushl and then execute ret. We have found method #2 is easier to use. The encoding of destinations for jmp is a bit tricky.
  • Here's a subtle point that has tripped up at least one group. When you're writing assembly code, the line:
    movl 0x12345678,%eax
    means "read 4 bytes at address 0x12345678 into register %eax." Since this is not a valid address, it will cause a segmentation fault. The line:
    movl $0x12345678,%eax
    means "put the number 0x12345678 into register %eax." It's easy to overlook that little '$,' but it makes a major difference in the behavior. A similar thing holds for the pushl instruction.
• Oct. 2
  • We've been looking over some of the failing solutions to L3 level 2 (dynamite). Based on this, we can give a few suggestions:
    • Your exploit string for this phase should only be 20 bytes long. Any longer than this, and you'll trash the stack frame for the function calling getbuf, and this will yield erratic behavior when getbuf attempts to return.
    • Our exploit string for this level encodes just 3 instructions: pushl, movl , and ret. If your's has much more than this, you're doing something wrong.
    • Don't start your string with padding to get to the position where you will overwrite the saved value of %ebp and the return address. Instead, use those first 12 bytes to hold your exploit code.
  • We've created a new version of bufbomb, called nbufbomb. This one does a better job testing for possible corruptions to the stack. This will reduce the chances that of false submissions, where the program states that you have passed a level, but our validation server does not accept it. The exploit strings for the two versions are slightly different (different stack positions and code addresses). So, you can continue working with bufbomb if you like, but we think you'll find nbufbomb less frustrating.
• Oct. 1
  • Be sure that your final submission at a given level is the correct one, because as of Monday, Oct. 1, the validation script will only check this one.
• Sept. 28
  • The validation script used by the server has been tightened up to detect cases where first bufbomb tells you it has succeeded, but then an error (generally a segmentation fault) occurs. The effect will be that more solutions will be indicated on the Web page as being invalid. If this happens to you, try to devise a different solution. Most likely, the problem is that you are not properly restoring the value of %ebp.