We help IT Professionals succeed at work.

BufBomb Firecracker

novice214 asked
Could someone walk me through the steps to solve the following problems? I would really like to understand how to solve this problem as opposed to just knowing the answer. So far I have been able to figure out the assembly/byte code needed to put my cookie into global_variable.


Level 2: Firecracker (30 pts)

A much more sophisticated form of buffer attack involves supplying a string that encodes actual machine instructions. The exploit string then overwrites the return pointer with the starting address of these instructions. When the calling function (in this case getbuf()) executes its ret instruction, the program will start executing the instructions on the stack rather than returning. With this form of attack, you can get the program to do almost anything. The code you place on the stack is called the exploit code. This style of attack is tricky, though, because you must get machine code onto the stack and set the return pointer to the start of this code.
Within the file bufbomb there is a function bang() having the following C code:

int global_value = 0;
void bang(int val)
entry_check(2); /* Make sure entered this function properly */
if (global_value == cookie) {
printf("Bang!: You set global_value to 0x%x\n", global_value);
printf("Misfire: global_value = 0x%x\n", global_value);
Similar to Levels 0 and 1, your task is to get bufbomb to execute the code for bang() rather than returning to test. Before this, however, you must set global variable global_value to your teams cookie. Your exploit code should set global_value, push the address of bang() on the stack, and then execute a return instruction to cause a jump to the code for bang().
Some Advice:

You can use GDB to get the information you need to construct your exploit string. Set a breakpoint within getbuf() and run to this breakpoint. Determine parameters such as the address of global_value and the location of the buffer.
Determining the byte encoding of instruction sequences by hand is tedious and prone to errors. You can let tools do all of the work by writing an assembly code file containing the instructions and data you want to put on the stack. Assemble this file with gcc and disassemble it with objdump. You should be able to get the exact byte sequence that you will type at the prompt. (A brief example of how to do this is included at the end of this writeup.)
Keep in mind that your exploit string depends on your machine, your compiler, and even your teams cookie. Do all of your work on the machine cs367.vsnet.gmu.edu, and make sure you include the proper team name on the command line to bufbomb.
Our solution requires 16 bytes of exploit code. Fortunately, there is sufficient space on the stack, because we can overwrite the stored value of %ebp. This stack corruption will not cause any problems, since bang causes the program to exit directly.
Watch your use of address modes when writing assembly code. Note that movl $0x4, %eax moves the value 0x00000004 into register %eax; whereas movl 0x4, %eax moves the value at memory location 0x00000004into %eax. Since that memory location is usually undefined, the second instruction will cause a segfault!
Do not attempt to use either a jmp or a call instruction to jump to the code for bang. These instructions uses PC-relative addressing, which is very tricky to set up correctly. Instead, push an address on the stack and use the ret instruction.
Watch Question

Top Expert 2009

Having the bytecode is an important step already.

What are you stuck on right now ?


I am having issues with the return address. When running through the code with GDB, I believe that the return address is at $ebp+4. If I do x/bx $ebp+4 I do see the start of my exploit code.

I really think I need an explanation on how to actually string together my exploit code, fillers, and the return address.

I think I need to input...

01 02 03 04 ... 32 90 90 90 90 [fillers]
c7 05 e8 c1 04 08 43 a3 53 76 68 23 90 04 08 c3 [16-bit exploit code]


either more more fillers and then my return address, but honestly this is kind of where I get stuck. Could you help me logically walk through how my input string and how it is executed?
Top Expert 2009
The return address is pushed on the stack when the function is called, ie. right before the function saves the old base pointer (ebp) on the stack.

Inside the function, the current base pointer points to the base of the current stack frame - ie. to the saved old base pointer.

So, you're right that the return address is at (ebp + 4). Your buffer overflow should overwrite this return address with the start of your exploit code. From what you explain, it seems you've succesfully done so.

The positioning of the exploit code within the buffer is up to you. Adding NOP instructions before the start of the exploit code makes it easier to determine a correct return address, because any address between the start of the NOPs and the start of the exploit code is fine.
If you can exactly determine the address of the start of the exploit code though, that doesn't really matter.

If you can get your exploit code to execute, follow it with gdb, and see what's going wrong, if anything.


Thank you so much. I've spent so much time on this already. I will go back and walk through GDB again. Hopefully I will be able to figure this out.