Linux-insides: Linux kernel load address randomization
1–10 of 12 posts
Re: Linux-insides: Linux kernel load address randomization
#2Re: Linux-insides: Linux kernel load address randomization
#3Re: Linux-insides: Linux kernel load address randomization
#4Am I the only one who sees this as gibberish and feels bad :(
Re: Linux-insides: Linux kernel load address randomization
#5Am I the only one who sees this as gibberish and feels bad :(
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.
Re: Linux-insides: Linux kernel load address randomization
#6http://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.
Re: Linux-insides: Linux kernel load address randomization
#7Re: Linux-insides: Linux kernel load address randomization
#8Outside 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?
Re: Linux-insides: Linux kernel load address randomization
#9https://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 C…
Re: Linux-insides: Linux kernel load address randomization
#10Outside 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).
So, outside of memory unsafety, is there another threat profile where ASLR gains you something?