Talk:Address space layout randomization

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
???	This article has not yet received a rating on Wikipedia's content assessment scale.
???	This article has not yet received a rating on the project's importance scale.

I propose that we discard all parts of this information revealing how security measures can be bypassed. 17:21, 10 November 2006 (UTC)

Wikipedia is not censored. --Tim1988 ^talk 17:24, 10 November 2006 (UTC)[reply]

Can't really see what needs cleaning up here. Some of the phrasing is a little clumsy but it seems minor. Soo 17:25, 8 January 2006 (UTC)[reply]

Can someone provide a link for the 1/n attack chance on Library Load Order Randomization ? Intuitively, it seems the chance is this high only when all libraries have the same sizes and are loaded in the same 'slots', so there is 1/n change to get the right slot.

Most likely it is assumed the attacker knows which libraries are being loaded and how big each one is. --Slashdevslashtty 04:53, 27 April 2006 (UTC)[reply]

English isn't my first language, so I can't correct the article. I hope someone reads this comment and edits it. As you can read from "On the Effectiveness of Address-Space Randomization di Hovav Shacham, Matthew Page, Ben Pfaff, Eu-Jin Goh, Nagendra Modadugu, Dan Boneh, In 14th Usenix Security Symposium, Oct. 2004" [1] an attacker has to do on average 2^(n-1) attacks on forking daemons and 2^n attacks on non-forking daemons or on daemons which crash at every try. "n" is not arbitrarly big, but it's the number of random bits that the ASLR can provide. For PaX implementation on i386 architecture "n" is 24 for stack addresses and 16 for heap and dinamically loaded libraries. A forking daemon (like Apache or Linux-ftpd from Linux NetKit) can be exploited with a return-into-libc attack with 32768 tries on average. It's difficult but it's not impossible. ASLR is "security through obscurity", it stops script kiddies, but it doesn't stops a resoluted attacker. Regards, IppatsuMan [2]

It's not security through obscurity; the attacker is assumed to know the design of the system. The missing information is similar in nature to an encryption key or a password. Script kiddies and resoluted attackers have the same chances of beating it; beating it relies on nothing more than sitting around for however long it takes to throw a LOT of attacks at it until you (by chance) get a successful hit. This is the same as brute forcing a password or encryption key. --John Moser 16:57, 22 June 2006 (UTC)[reply]

You can actually quantify exact probabilities for a number of attempts for a number of bits (where bits compensates for the attacked bits per attempt) and show what percentage chance an attacker has at success. The PaX documentation on ASLR does this.

Computational cost

Hello,

Is there any indication of the computational cost of this, either in theory or in real world systems? 60.241.185.216 13:53, 22 December 2006 (UTC)[reply]

ASLR on Leopard

The link saying ASLR on Leopard is ineffective is not a credible source. The author prefers to use a GUI for ipfw, and for some reason overlooked how normal it is for ports to open when services are shared, users don't need or want to manually open ports when they purposely enable sharing. His credibility about ASLR is non-existent, nor is there any information at all about ASLR's implementation or weakness with regards to Apple's implementation. I recommend the removal about the part of it being ineffective, it seems to be media spin, there is no article so far about the process of bypassing it as the claim seems to debunk its effectiveness. —Preceding unsigned comment added by 66.82.9.59 (talk) 09:18, 31 December 2007 (UTC)[reply]

My credibility about ASLR is pretty high, and Leopard ASLR is totally ineffective; it fails to randomize core runtime libraries that can be used to execute code. For instance, attackers can ret-to-dyld to invoke code in the dynamic linker. This is all pretty well covered in available sources. --- tqbf 18:33, 31 December 2007 (UTC)[reply]

Vista

So if this security feature is only for those who declare themselves workable (which doesn't make sense, there's another layer before what programs see), how does it help at all? —Preceding unsigned comment added by 86.164.161.55 (talk) 21:13, 6 August 2008 (UTC)[reply]

Windows?

I believe that there are too many links about Vista. I've counted - 4/9, almost half.

Perhaps there should be one or two, and an implementation or similar. --Darkuranium (talk) 20:00, 15 September 2008 (UTC)[reply]

Does this make debugging harder?

Does anyone know whether ASLR causes any problems for memory debugging? Probably not for something like strace, but I'm thinking in terms of running a virtual machine, then forensically looking through its memory for something. Would ASLR make that target harder to find?