Talk:Address space layout randomization

From Wikipedia, the free encyclopedia
Jump to: navigation, search
          This article is of interest to the following WikiProjects:
WikiProject Computer Security / Computing  (Rated C-class, High-importance)
WikiProject icon This article is within the scope of WikiProject Computer Security, a collaborative effort to improve the coverage of computer security 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.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 High  This article has been rated as High-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Computing.
WikiProject Software / Computing  (Rated C-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Software, a collaborative effort to improve the coverage of software 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.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Computing.

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[edit]


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

ASLR on Leopard[edit]

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 (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)


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 (talk) 21:13, 6 August 2008 (UTC)


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 (talk) 07:20, 26 March 2010 (UTC)

Does this make debugging harder?[edit]

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 (talk) 06:31, 26 March 2009 (UTC)

ASLR on Linux[edit]

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? (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)

HEAP ASLR on Linux (maybe since 3.1)[edit]

Looks like at least since Linux 3.1 there's an HEAP ASLR possible.

Additionally enable heap randomization. This is the default if CONFIG_COMPAT_BRK is disabled.

On my system (openSUSE 12.1) it was switched off at first but I could easily change the randomize_va_space setting like described in the documentation.

In older kernel sources (this is from 2.6.30) I found the following text. I don't know if that means that HEAP ASLR was always on or if CONFIG_COMPAT_BRK activated was standard, so HEAP ASLR was usually switched off.

However there is a CONFIG_COMPAT_BRK option for systems with ancient and/or broken binaries, that makes heap non-randomized, but keeps all other parts of process address space randomized if randomize_va_space sysctl is turned on.

Using the stack as a reference[edit]

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 (talk) 03:58, 19 March 2010 (UTC)

ASLR Performance penalty ?[edit]

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 ?[edit]

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. -- (talk) 06:41, 7 December 2011 (UTC)

Yeah, I'm not sure why they say it can't be disabled in Win 7 without EMET. I literally just did it on a VM running Win 7 x64, and rebooted, and confirmed it worked for a process previously affected by ASLR. Also, when I open EMET, it says ASLR is Disabled, under "System Status." I vote to remove the false claim, but leave in the fact that it can be controlled with EMET. JonathonReinhart (talk) 03:04, 11 April 2012 (UTC)