Basic C program with an obvious buffer overflow:
void f(){
char buf[100];
gets(buf);
printf("Hello exploit");
}
int main(){
f();
return 0;
}
Shellcode for the correct system: http://www.shell-storm.org/shellcode/files/shellcode-811.php I've put a NOP sled at the front and the correct return address at the back.
When running the exploit in gdb, I can see that the return address is correctly altered, the execution jumps to my nop sled and continues with the shellcode. I can step through the start of the shellcode, but it segfaults near the end.
(gdb) c
Continuing.
Breakpoint 4, 0xbffff710 in ?? ()
1: x/i $pc
=> 0xbffff710: xor %eax,%eax
(gdb) stepi
0xbffff712 in ?? ()
1: x/i $pc
=> 0xbffff712: push %eax
(gdb) stepi
0xbffff713 in ?? ()
1: x/i $pc
=> 0xbffff713: push $0x68732f2f
(gdb) stepi
0xbffff718 in ?? ()
1: x/i $pc
=> 0xbffff718: push $0x6e69622f
(gdb) stepi
0xbffff71d in ?? ()
1: x/i $pc
=> 0xbffff71d: mov %esp,%ebx
(gdb) stepi
0xbffff71f in ?? ()
1: x/i $pc
=> 0xbffff71f: mov %eax,%ecx
(gdb) stepi
0xbffff721 in ?? ()
1: x/i $pc
=> 0xbffff721: mov %eax,%edx
(gdb) stepi
0xbffff723 in ?? ()
1: x/i $pc
=> 0xbffff723: mov $0x2f,%al
(gdb) stepi
0xbffff725 in ?? ()
1: x/i $pc
=> 0xbffff725: bound %ebp,0x6e(%ecx)
(gdb) stepi
Program received signal SIGSEGV, Segmentation fault.
The program has an executable stack (execstack -s vulnerableApp
) and ASLR is off.
So three questions:
- Where does the bound instruction come from? The shellcode from the url doesn't have a bound oppcode
- Why is it segfaulting?
- How can I fix it? (I'd rather understand what's going on here, then trying different shellcodes)
-- Edit I forgot to mention that I've used this shellcode on the same system to exploit a different binary and it worked.
UPDATE
Yes, the shellcode is delivered in its entirety:
0xbffff6f6: 0x90909090 0x90909090 0x90909090 0x90909090
0xbffff706: 0x90909090 0x90909090 0xc0319090 0x2f2f6850
0xbffff716: 0x2f686873 0x896e6962 0x89c189e3 0xcd0bb0c2
0xbffff726: 0x40c03180 0xf48680cd 0x8400bfff 0x00000804
0xbffff736: 0x00000000 0x44d30000 0x0001b7e4 0xf7d40000
You can see the sled, followed by the exploit.