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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

It's not always going to be possible, and that wasn't my position. My
position, however, is that return-to-libc is always a nice option. There
are tons of possibilities for exploitation available but your platform 
and
application are going to direct you to your most elegant approach. One
must focus on the environment, itself, rather than try and create a 
generic
approach to a specific problem.

Sure, you're going to see nil bytes sometimes, but there are ways to
get around them (especially if you're working with binary data and not
strings). The jmp/call *%REG example being posted on this mailing list
is a decent example of another method. However, that method is not
always going to work and won't necessary be as easy to utilize across
different architectures that don't allow for such simple call/register
semantics.

I think the best thing to do here is to introduce people that are new to
problems of ASLR, etc, to different options such as return to libc. This
allows them to broaden their mind and further speculate on more
creative approaches to exploitation. But, start them out easy first :-)
No-one starts out studying calculus in mathematics.

Don "north" Bailey

-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.0.5 (Build 5050)

iQA/AwUBRDHpCV/Ie1ANMtLuEQKNmACeP5x7P6SSfamQjTn2dhewJtuL7gkAoN8l
bH+FEiF5jXxCxr47rJMxA8av
=b/jw
-----END PGP SIGNATURE-----