Vulnerability Development mailing list archives
Re: Beating memory address randomization (secuirty) features in Unix/Linux
From: Don Bailey <don.bailey () gmail com>
Date: Mon, 3 Apr 2006 21:33:29 -0600
-----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-----
Current thread:
- Re: Beating memory address randomization (secuirty) features in Unix/Linux Kaveh Razavi (Apr 03)
- Re: Beating memory address randomization (secuirty) features in Unix/Linux Don Bailey (Apr 04)
- Re: Beating memory address randomization (secuirty) features in Unix/Linux The Jabberwock (Apr 04)
- Re: Beating memory address randomization (secuirty) features in Unix/Linux Kaveh Razavi (Apr 04)
- Re: Beating memory address randomization (secuirty) features in Unix/Linux The Jabberwock (Apr 04)
- Re: Beating memory address randomization (secuirty) features in Unix/Linux Kaveh Razavi (Apr 04)