• RSS
  • Twitter
  • FaceBook

Security Forums

Log in

FAQ | Search | Usergroups | Profile | Register | RSS | Posting Guidelines | Recent Posts

overflows in ubuntu breezy

Users browsing this topic:0 Security Fans, 0 Stealth Security Fans
Registered Security Fans: None
Post new topic   Reply to topic   Printer-friendly version    Networking/Security Forums Index -> Exploits // System Weaknesses

View previous topic :: View next topic  
Author Message
Julio
Just Arrived
Just Arrived


Joined: 03 Dec 2003
Posts: 0


Offline

PostPosted: Sat Dec 03, 2005 9:22 pm    Post subject: overflows in ubuntu breezy Reply with quote

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?
Back to top
View user's profile Send private message
zeedo
SF Reviewer
SF Reviewer


Joined: 01 Sep 2004
Posts: 24
Location: Scotland

Offline

PostPosted: Sun Dec 04, 2005 1:44 am    Post subject: Reply with quote

That is due to the stack protection in Linux 2.6, it adds some randomisation.

You can switch this off by running the commands below.

Code:

 sudo bash -c 'echo "kernel.randomize_va_space = 0" >> /etc/sysctl.conf'
 sudo /sbin/sysctl -p

Back to top
View user's profile Send private message Send e-mail Visit poster's website AIM Address Yahoo Messenger MSN Messenger
Julio
Just Arrived
Just Arrived


Joined: 03 Dec 2003
Posts: 0


Offline

PostPosted: Sun Dec 04, 2005 2:39 am    Post subject: Reply with quote

Thanks! Very Happy

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]
Back to top
View user's profile Send private message
zeedo
SF Reviewer
SF Reviewer


Joined: 01 Sep 2004
Posts: 24
Location: Scotland

Offline

PostPosted: Sun Dec 04, 2005 2:15 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Send e-mail Visit poster's website AIM Address Yahoo Messenger MSN Messenger
Display posts from previous:   

Post new topic   Reply to topic   Printer-friendly version    Networking/Security Forums Index -> Exploits // System Weaknesses All times are GMT + 2 Hours
Page 1 of 1


 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Community Area

Log in | Register