[prev in list] [next in list] [prev in thread] [next in thread] 

List:       vuln-dev
Subject:    Re: Beating memory address randomization (secuirty) features in
From:       The Jabberwock <jabberwock () tenebrous ! com>
Date:       2006-04-04 14:57:27
Message-ID: 44328957.3010602 () tenebrous ! com
[Download RAW message or body]

This is a tough one. The only things I can recommend is that you look 
for the address of a JMP instruction that jumps to the address of execve 
(but this is a slim chance), or perhaps look for an address to memcpy 
and jump to that and overflow the next stack frame with jumps to execve..

Sorry I couldn't help you more. On the up side,  your box is pretty well 
protected :)

Kind regards,
The Jabberwock


Kaveh Razavi wrote:
> ok here are some of my results I gathered too :)
>
> ----------------
> [ihsteam.com]$ uname -a
> Linux server011.virtuosonetsolutions.com 2.6.15.4 #1 SMP Sat Feb 11
> 02:15:53 IRST 2006 i686 i686 i386 GNU/Linux
> [ihsteam.com]$ ldd /bin/ls
>         linux-gate.so.1 =>  (0xffffe000)
>         librt.so.1 => /lib/tls/librt.so.1 (0x00889000)
>         libacl.so.1 => /lib/libacl.so.1 (0x0085e000)
>         libselinux.so.1 => /lib/libselinux.so.1 (0x0084c000)
>         libc.so.6 => /lib/tls/libc.so.6 (0x0072e000)
>         libpthread.so.0 => /lib/tls/libpthread.so.0 (0x008ea000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00715000)
>         libattr.so.1 => /lib/libattr.so.1 (0x00873000)
> [ihsteam.com]$ cat /etc/fedora-release
> Fedora Core release 2 (Tettnang)
> [ihsteam.com]$
> ---------------
> libacl.so.1 => /lib/libacl.so.1 (0x00ab8000)
> libtermcap.so.2 => /lib/libtermcap.so.2 (0x00fb9000)
> libc.so.6 => /lib/tls/libc.so.6 (0x00709000)
> libattr.so.1 => /lib/libattr.so.1 (0x004b6000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00f5e000)
> ( I dunno what the distro is , my friend pasted it up , it is x86 for sure )
> ---------------
> root@serevr251 [/etc/init.d]# ldd /bin/ls
>         librt.so.1 => /lib/tls/librt.so.1 (0x0037b000)
>         libacl.so.1 => /lib/libacl.so.1 (0x00304000)
>         libselinux.so.1 => /lib/libselinux.so.1 (0x0036b000)
>         libc.so.6 => /lib/tls/libc.so.6 (0x001d7000)
>         libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00341000)
>         /lib/ld-linux.so.2 (0x001bd000)
>         libattr.so.1 => /lib/libattr.so.1 (0x00355000)
> root@serevr251 [/etc/init.d]# uname -a;cat /etc/redhat-release
> Linux serevr251.liquidweb.com 2.6.9-1.667smp #1 SMP Tue Nov 2 14:59:52 EST
> 2004 i686 i686 i386 GNU/Linux
> Fedora Core release 3 (Heidelberg)
> root@serevr251 [/etc/init.d]#
> ---------------
>
> Jabberwock here it is , you can see the address of system , execve starts
> with null byte :/ .
>
> root@serevr251 [/home/test]# echo "main(){}">ex.c;gcc ex.c -o ex;gdb ./ex
> GNU gdb Red Hat Linux (6.1post-1.20040607.41rh)
> 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 "i386-redhat-linux-gnu"...(no debugging symbols
> found)...Using host libthread_db library "/lib/tls/libthread_db.so.1".
>
> (gdb) b main
> Breakpoint 1 at 0x804833a
> (gdb) r
> Starting program: /home/test/ex
> (no debugging symbols found)...(no debugging symbols found)...
> Breakpoint 1, 0x0804833a in main ()
> (gdb) p system
> $1 = {<text variable, no debug info>} 0x20b5b0 <system>
> (gdb) p execve
> $2 = {<text variable, no debug info>} 0x261910 <execve>
> (gdb)
>
> ----------
>
> Regards
> Kaveh Razavi
> Network Security Researcher
>
>
>   
>> As long as libc is linked in the vulnerable program it can be returned
>> to, and the shellcode generated is often significantly smaller than
>> typical syscall shellcode.
>>
>> Do you have the gdb output portraying the libc function addresses that
>> begin with nullbytes?
>>
>> The Jabberwock
>>
>>
>> Kaveh Razavi wrote:
>>
>>     
>>> I saw null byte at the first byte of libc addresses like system execve
>>> etc..
>>> I was running 2.6.13 kernel on a x86 32 bit architecture ( slackware 10.2
>>> )
>>> also I saw it when I tried to exploit a tiny application on another
>>> 32/x86
>>> running a 2.6.10 kernel ( slackware 10 ) .
>>> I checked again ( after your reply ) on my new 64/x86 running the lastest
>>> version of kernel ( 2.6.16 slackware 10.2 ) and there was no null byte at
>>> the first.
>>> thanks for your reply but no idea if ret-tolibc is always possible .
>>>
>>> Kaveh Razavi
>>> Network Security Researcher
>>>
>>>
>>>
>>>       
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>>
>>>> Erm, what "distros" are you talking about? I run the latest
>>>> Gentoo on sparc64, pa-risc and ppc and none of them
>>>> have a nil byte in libc addresses. Besides, that doesn't
>>>> always matter.
>>>>
>>>> Think deeper, you're not always working with strings.
>>>>
>>>> Below are some pastes of functionality on different
>>>> architectures. Notice the only one that actually shows
>>>> nil bytes is sparc64, but you wont have to worry about
>>>> that because you're not going to jump to the first 255
>>>> bytes.
>>>>
>>>> Don "north" Bailey
>>>>
>>>> Here's SuSE on x86
>>>>
>>>> givingtree.north % ./showstack
>>>> &buffer[0]=bf9947b7
>>>> givingtree.north % ./showstack
>>>> &buffer[0]=bff50067
>>>> givingtree.north % ldd ./showstack
>>>>         linux-gate.so.1 =>  (0xffffe000)
>>>>         libc.so.6 => /lib/tls/libc.so.6 (0xb7e39000)
>>>>         /lib/ld-linux.so.2 (0xb7f59000)
>>>> givingtree.north % uname -mr
>>>> 2.6.16-rc6-givingtree i686
>>>> givingtree.north %
>>>>
>>>>
>>>> Here's Gentoo on PA-RISC
>>>>
>>>> visualize.north % ./showstack
>>>> &buffer[0]=faf2c5c8
>>>> visualize.north % ./showstack
>>>> &buffer[0]=fb16a5c8
>>>> visualize.north % ldd showstack
>>>>         libc.so.6 => /lib/libc.so.6 (0x406ad000)
>>>>         /lib/ld.so.1 => /lib/ld.so.1 (0x4037d000)
>>>> visualize.north % uname -mr
>>>> 2.6.16-rc5-visualize parisc
>>>> visualize.north %
>>>>
>>>>
>>>> Here's Gentoo on sparcv9
>>>>
>>>> blueberry.snow % ./showstack
>>>> &buffer[0]=ef80d997
>>>> blueberry.snow % ./showstack
>>>> &buffer[0]=efeed997
>>>> blueberry.snow % ldd showstack
>>>>         libc.so.6 => /lib/libc.so.6 (0x70030000)
>>>>         /lib/ld-linux.so.2 (0x70000000)
>>>> blueberry.snow % uname -mr
>>>> 2.6.16.1-blueberry sparc64
>>>> blueberry.snow %
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: PGP Desktop 9.0.5 (Build 5050)
>>>>
>>>> iQA/AwUBRC2mpV/Ie1ANMtLuEQKRCgCg0xBuYb2UX66el7eKeA3LDNhsXGoAn32k
>>>> HVnpOIYhjgAzCzoDeSd7V5G/
>>>> =o9Xn
>>>> -----END PGP SIGNATURE-----
>>>>
>>>>
>>>>
>>>>
>>>>         
>>>
>>>       
>>
>>     
>
>   

[prev in list] [next in list] [prev in thread] [next in thread]