Dear c0ntex, --Friday, May 26, 2006, 11:12:41 AM, you wrote to davidl@xxxxxxxxxxxxxxx: 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/
