Talk:Address space layout randomization

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)

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)

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)

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)

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)

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)

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)

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)

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)

It seems something is missing in the last sentence of the first paragraph (When registry key ...). —Preceding unsigned comment added by 195.168.53.57 (talk) 07:20, 26 March 2010 (UTC)

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? —Preceding unsigned comment added by 24.69.66.122 (talk) 06:31, 26 March 2009 (UTC)

ASLR on Linux

The Documentation/sysctl/kernel.txt file says that ASLR is disabled by default. I could not find anything in the sources where "a weak form of ASLR is enabled since 2.6.12" - where is that information from? 62.216.212.168 (talk) 07:20, 30 March 2009 (UTC)

I just tested Ubuntu 10.10, 32-bit ASLR, and it randomizes the mmap base by 512 locations, over a range of 2MB. As far as I know, Ubuntu uses the Exec Shield patch, which means that the current information on the page is invalid (256 locations/1MB). Ed McMan (talk) 19:12, 25 August 2011 (UTC)

Using the stack as a reference

How would this prevent an attacker overflowing the stack and then grabbing further memory references that were previously pushed deeper into the stack to get usable code section address ? —Preceding unsigned comment added by 221.127.24.186 (talk) 03:58, 19 March 2010 (UTC)

ASLR Performance penalty ?

I think it could be useful to provide some information on the possible performance penalty that ASLR can incur.

Consider for example a CPU with cache executing a loop where each iteration calls a function that places some data on the stack or each iteration calls malloc() + free(). In each iteration the size of this temporary data is the same and fits inside the CPU cache with room to spare.

In the absence of ASLR each iteration may very well store that data on the same address range. This means that the data will be cached in the same location in the CPU cache. Other parts of the CPU cache can therefore cache other data across all the iterations, thereby potentially reducing cache misses. With ASLR each iteration will very likely store the data on different address ranges. This can cause the data to be cached in different locations in the CPU cache. This in turn can force other data out of the CPU cache in each iteration, thereby incurring expensive cache misses.

Similar examples could probably be constructed for other levels of a hierarchical memory layout.

The above is just something I thought of, so even if correct it is probably not suitable for the article. I believe however that it justifies a section in the article discussing either the potential performance penalties of ASLR - or why there can be no ASLR performance penalties, if that is the case. Lklundin (talk) 07:56, 19 August 2011 (UTC)

the MoveImages registry setting has no effect in Windows 7 ?

However, only MoveImages was changed when ASLR status changed by Enhanced Mitigation Experience Toolkit. And, ASLR was able to be disable even when only MoveImages was changed without using Enhanced Mitigation Experience Toolkit. --211.127.229.23 (talk) 06:41, 7 December 2011 (UTC)