User: Password:
|
|
Subscribe / Log in / New account

Random numbers for ASLR

Random numbers for ASLR

Posted May 14, 2009 15:18 UTC (Thu) by copsewood (subscriber, #199)
In reply to: Random numbers for ASLR by bvdm
Parent article: Random numbers for ASLR

The question Linus raised concerns how much slower can we accept a kernel everyone uses in order to defend against a secondary attack against address space layout randomisation defences (ASLR) against a primary class of attack (buffer or heap overflow) when insufficient bits of entropy are available within the ASLR defence to prevent brute force attacks against this defence in the first place. If 8 bits of genuine entropy are available, this makes a successful buffer overflow exploit work one in 2**8 i.e. 256 times attempted compared to without ASLR, and if 16 bits are available the exploit might work one in 2**16 times given a fully unpredictable ASLR within this set of permutations compared to a system without ASLR.

So the whole point of ASLR isn't to make a buffer or heap attack impossible, but to make it more difficult for an attacker to have code of their choosing executed by a vulnerable application, which is hopefully more likely to crash when an exploit is attempted than give a privilege escalation to the attacker. In a more fully secure system, the attacker wouldn't be able to carry out the primary buffer or heap overflow attack on a vulnerable application through an unvalidated input method, because these primary security bases would have been dealt with first; ASLR is a second line of defence and not the first.

So if the ASLR coding is too performance expensive it will have to be a compile time option and too few people will compile it in to make it of any use to them at all. Better to have enough speed that it doesn't have to be an option and to have enough unpredictability so those trying to defeat it are more likely to use brute force than PRNG state prediction.


(Log in to post comments)

Random numbers for ASLR

Posted May 14, 2009 20:55 UTC (Thu) by wahern (subscriber, #37304) [Link]

This argument is pure misdirection. There should be little doubt that cryptographically strong PRNGs exist which are just as performant as whatever ridiculous MD4 hack is being used now. Clearly there are cryptographers falling over themselves to try provide the code to Linus & Co.; he's just not hearing it.

Use a strong PRNG now, and worry (or not worry, as it may be) about ASLR entropy later. But who's going to care about the latter if the former would be the weak chain, regardless.

And let's not forget that there's an army of wholly untalented OEM engineers who will follow Linus & Co's lead, and will be (and surely are) using this inadequate PRNG for sundry cases in existing products, mimicking the same, poor calculus Linus uses in his stubborn defense.

Random numbers for ASLR

Posted May 14, 2009 21:47 UTC (Thu) by nix (subscriber, #2304) [Link]

There should be little doubt that cryptographically strong PRNGs exist which are just as performant as whatever ridiculous MD4 hack is being used now. Clearly there are cryptographers falling over themselves to try provide the code to Linus & Co.; he's just not hearing it.
If so, they're not doing it in that thread. Matt presented a PRNG that was twice as slow as the existing (crappy but cheap) MD4 one, to be used in time-critical contexts like process execution. That's not going to fly, given that that path has attention paid to every last cycle.

Random numbers for ASLR

Posted May 15, 2009 11:55 UTC (Fri) by man_ls (guest, #15091) [Link]

Linus wanted to speak about a small % instead of a big factor. Just from reading the article Ingo provided the answer: looking at the numbers in context we are talking about a 1% performance hit in fork(). If your system is completely CPU-bound and fork() takes half the CPU then your task will take 0.5% more to execute (seven extra minutes every day). I think it is quite acceptable for even a small increase in security.

Random numbers for ASLR

Posted May 15, 2009 12:33 UTC (Fri) by hppnq (guest, #14462) [Link]

If you genuinely worry about address space related exploits, you will know that ASLR is not really going to save the day regardless of the RNG used, although obviously some randomization is needed.

Random numbers for ASLR

Posted May 15, 2009 18:17 UTC (Fri) by nix (subscriber, #2304) [Link]

ASLR can make attacks very much harder, but only on 64-bit systems (and of
course only if more than 8 bits of randomness is used). On 32-bit there
isn't the room to make attacks significantly harder :(


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds