Re: Beating memory address randomization (secuirty) features in Unix/Linux



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-----