Lab 3 - Hacking a buffer bomb
Lab 3 is due Thursday, October 4 at 11:59pm. You only have a little
more than a week for this lab, so get started soon.
- 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
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:
means "read 4 bytes at address 0x12345678 into register %eax." Since this is not a valid address, it will cause a segmentation fault.
means "put the number 0x12345678 into register
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.
Last modified: Wed Oct 03 2001