Dear c0ntex,
--Friday, May 26, 2006, 11:12:41 AM, you wrote to davidl@ngssoftware.com:
c> Since ASLR has been in and has been trivially circumvented in Linux
c> for years now (see my papers on return-to-libc & return-to-got) I
c> don't see it being a particularly hard issue to defeat :-) Maybe
c> though, if they also randomise some other key areas like heap
c> locations and do some fancy relocation to non writable/executable
c> pages plus the drop-in of some ascii armour, we might then be on par
c> with a hardened Linux or *BSD..
c> Granted, I haven't looked at Vista yet :)
Bypassing canary word? It's easy. Bypassing Non-executable stack/heap?
OK. Bypassing ASLR? May be. Bypassing canary word + non-executable +
ASLR? Not so trivially. Neither return-to-library nor return-to-(IAT?)
fight randomization. The only actual way you mention in your articles is
function address bruteforcing (sorry if I miss something). Bruteforcing
is not always possible. Bruteforcing on growing 64-bit systems.... Good
luck. Don't forget, unlike POSIX systems, single-thread application
under Windows is something extremely rare and stack/heap addresses are
usually not predictable too. Don't forget, that there is no such thing
as 'suid' and exploitable applications are usually long-living, making
it even more harder. Quoting one good guy with 'C0ntex' nick:
-=-=-=-=-=-=-=-=-
Using the above protection methods does not stop attacks against programming
mistakes but it certainly makes it much harder to be successful and as such,
each solution will prove better than nothing at all.
-=-=-=-=-=-=-=-=-
--
~/ZARAZA
http://www.security.nnov.ru/
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
