Linux-insides: Linux kernel load address randomization
github.comhttps://thehackernews.com/2017/02/bypass-aslr-browser-javasc...
http://www.cs.vu.nl/~herbertb/download/papers/anc_ndss17.pdf
XI. CONCLUSIONS
In this paper, we described how ASLR is fundamentally insecure on modern architectures. Our attack relies on the interplay between the MMU and the caches during virtual to physical address translation—core hardware behavior that is central to efficient code execution on modern CPUs. The underlying problem is that the complex nature of modern microarchitectures allows attackers with knowledge of the architecture to craft a carefully chosen series of memory accesses which manifest timing differences that disclose what memory is accessed where and to infer all the bits that make up the address. Unfortunately, these timing differences are fundamental and reflect the way caches optimize accesses in the memory hierarchy. The conclusion is that such caching behavior and strong address space randomization are mutually exclusive. Because of the importance of the caching hierarchy for the overall system performance, all fixes are likely to be too costly to be practical. Moreover, even if mitigations are possible in hardware, such as separate cache for page tables, the problems may well resurface in software. We hence recommend ASLR to no longer be trusted as a first line of defense against memory error attacks and for future defenses not to rely on it as a pivotal building block.
In every context that I've seen it, ASLR is there to be annoying to circumvent instead of being the sole line of defense. Generally other techniques are present as well to mitigate the risk of such an attack.
An informative read on ASLR: https://blog.polyverse.io/why-aslr-stops-rop-attacks-8e961ca...
Outside of Linux, is there any point to ASLR in a provably memory safe kernel like sel4? Like, I get the main point is to stop ROP gadgets, which obviously aren't an issue when you can't corrupt memory. Are there side benefits though?
Formally verified kernels are pretty rare, and you can always have bugs in verification or side channel attacks that your proofs don’t cover, like speculative execution timing bugs in your CPU. (K)ASLR doesn’t defeat all memory bugs but it helps (a little). It is a very low overhead element of defense in depth that doesn’t require major code changes (unlike say, rewriting your kernel in a memory safe language).
Sure, but those same speculative execution attacks also trivially defeat ASLR. And practically speaking, memory safety in formally proved software tends to be pretty bullet proof.
So, outside of memory unsafety, is there another threat profile where ASLR gains you something?
Sure, consider that the hashCode() of objects in Java are based on memory addresses, which means they’re predictable to an attacker without ASLR.
Am I the only one who sees this as gibberish and feels bad :(
I don't think a lot of people can jump into Page 6 of a document called Kernel booting process and understand it.
It requires knowing something about the topic, and maybe some of those who don't would have to look up and read about 1, 2, 5, 10 different topics that show up in the article that they didn't know about before.
The only cure for ignorance is knowledge. Stop doubting and being afraid and go learn...