Talk:Address space layout randomization/Archive 1

Archive 1

Comment on cleanup tag

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)

Reference for attack chance on Library Load Order Randomization?

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.

We should discard info on bypassing security measures

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)

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)

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)

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)

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)

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)

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)

HEAP ASLR on Linux (maybe since 3.1)

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.

• https://www.kernel.org/pub/linux/kernel/v3.0/linux-3.1.tar.xz (File /linux-2.6.30.10/Documentation/sysctl/kernel.txt)
• https://www.kernel.org/doc/Documentation/sysctl/kernel.txt

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.

• https://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.30.10.tar.xz (File /linux-2.6.30.10/Documentation/sysctl/kernel.txt)

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)

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)

External links modified

Hello fellow Wikipedians,

I have just added archive links to 2 external links on Address space layout randomization. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive https://web.archive.org/20120301211503/http://www.securityarchitects.com/products.html to http://www.securityarchitects.com/products.html
• Added archive https://web.archive.org/20110525190329/http://www.apple.com:80/macosx/security/ to http://www.apple.com/macosx/security/#sixtyfour

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 10:33, 8 January 2016 (UTC)

I found where the first of the links moved, and tweaked the second one to go to the appropriate section. Guy Harris (talk) 21:13, 8 January 2016 (UTC)

ASLR on FreeBSD

Current information on ASLR in FreeBSD is just false. The whole ASLR section for FreeBSD is promoting a FreeBSD fork known as HardenedBSD, one of which's main developers attempted to introduce ASLR in FreeBSD. However he abandoned the development after a few months as the following link proves https://reviews.freebsd.org/D473

The following part is even worse speculation and hoax attempt:

"An attempt to introduce ASLR to FreeBSD was abandoned on 19 December 2015 because of unwillingness of FreeBSD developers to include the proposed ASLR implementation." - this is just not true, where even the reference used proves that development was abandoned.

I've also reverted edits to FreeBSD ASLR section, where someone was promoting OPNsense (yet again) in this section, from German IP 78.55.101.49. I suspect edit war will start now.

Official ASLR implementation in FreeBSD is on the way, but nobody seems to be pointing that out https://reviews.freebsd.org/D5603

I'm setting up this talk section so everyone can discuss--Mr.hmm (talk) 17:13, 12 September 2016 (UTC)

No sense in adding to the drama. Just leave it out until FreeBSD actually has AS(L)R, at which point you can add a sourced paragraph mentioning that it does. DES (talk) 00:09, 9 October 2016 (UTC)

Lack of source isn't grounds for summary deletion unless no sources exist. Add a "citation needed" if you think the summary really needs a cite, but this information is all online. Sources exist. KMeyer (talk) 21:44, 11 October 2016 (UTC)

Would you prefer “it is indeed a contentious issue and even your allegedly NPOV text is neither correct nor neutral and any attempt to correct it will just devolve into a flame war, therefore let's just leave it out until kib's patch has been committed”? DES (talk) 17:37, 20 October 2016 (UTC)

Can you please point out what you believe is incorrect or not neutral, rather than edit warring? KMeyer (talk) 20:03, 25 October 2016 (UTC)

Your text is incomplete because it omits a) the reason why the patch was in review for two years (because there were serious technical issues which Pinter and Webb refused to address) b) the reason why they abandoned it (because they started a competing project) and c) the reason why Belousov's patch still hasn't been committed (because Webb is doing his best to drag out the review process). It is not neutral because by omitting these factors, it supports Pinter and Webb's narrative wherein FreeBSD developers are resistant to change and naïve or ignorant about security. TL;DR: it's a shit show, keep Wikipedia out of it. DES (talk) 23:38, 25 October 2016 (UTC)

Hm, I thought that mentioning Shawn et al abandoned their patch and Konstantin had to write a new one from scratch made it pretty clear there were serious flaws in the original that went unaddressed for 2-3 years. But, have it your way. KMeyer (talk) 00:38, 27 October 2016 (UTC)

Nintendo 3DS and (lack of?) ASLR

Mention of the Nintendo 3DS in the article was removed with the edit comment

“ Nintendo 3DS doesn't randomize address space layout but the location of code pages in physical memory. It's not ASLR, and so not relevant to the article. ”

So what is the point then? To try to evade hacking attempts that depend on predictable physical addresses?

And couldn't this be described as a related mechanism? Couldn't a system that used no address translation at all still randomize physical address assignments, and thereby be thought of as doing ASLR? It's not called VASLR...

Aside: Most of the virtual memory OSs I'm familiar with don't do anything to deliberately randomize physical page addresses, but they don't try to maintain any particular sequence either, except of course for DMA "bounce buffers" and other things that need it. Things that happen early in boot do tend to end up at fairly predictable addresses. Not as much for things that happen later.

Jeh (talk) 17:18, 3 February 2017 (UTC)

The Nintendo 3DS does perform address translation, and the virtual address layout is completely unchanged by the physical address layout, that's why that randomization can't be considered as ASLR.

For the point of that randomization: the GPU of the Nintendo 3DS can access a large part of the main RAM, including the current "main application" code, normally protected against writing.

One can abuse the GPU to change those pages and so be able to have arbitrary executable code.

Nintendo introduced a randomization of the physical position of code pages for select titles to prevent reliable code overwriting.

However it's just an inconvenience as one can abuse the GPU in a similar way to read the layout and adapt the writes. It requires more work but is an universal bypass.

Motezazer (talk) 16:37, 5 February 2017 (UTC)