Re: Beating memory address randomization (secuirty) features in Unix/Linux
- From: "Kaveh Razavi" <c0d3r@xxxxxxxxxxx>
- Date: Sat, 1 Apr 2006 14:50:38 +0430 (IRDT)
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-----
- Follow-Ups:
- Re: Beating memory address randomization (secuirty) features in Unix/Linux
- From: The Jabberwock
- Re: Beating memory address randomization (secuirty) features in Unix/Linux
- From: Don Bailey
- Re: Beating memory address randomization (secuirty) features in Unix/Linux
- Prev by Date: Re: Delphi and buffer overflows
- Next by Date: Re: Beating memory address randomization (secuirty) features in Unix/Linux
- Previous by thread: Re: Beating memory address randomization (secuirty) features in Unix/Linux
- Next by thread: Re: Beating memory address randomization (secuirty) features in Unix/Linux
- Index(es):
Relevant Pages
|