ASLR on the Line: Practical Cache Attacks on the MMU [pdf]
cs.vu.nl
cs.vu.nl
ASLR is a mitigation measure meant to considerably increase the effort an attacker has exert at a relatively small performance cost, nothing more. It does that quite well. Personally, I'm just happy it's easy to disable for performance reasons and I hope there won't be any attempt to mitigate this attack at the hardware level on general purpose CPUs.
Consider: keeping crypto keys secret is a fundamental requirement of basically every secure system. That means they're "obscured," but it's not security through obscurity.
When it comes to ASLR, the locations of code within the address space are in pretty much the same role as crypto keys. The problem isn't that it's security through obscurity, it's that there are ways to leak the contents of those "keys," and they aren't very large.
ASLR doesn't violate Kerckhoffs' principle.
1. ASLR changed the way exploits are written, not just by requiring new techniques but (often) by requiring attackers to find additional bugs to chain to make exploits work. In the history of memory corruption countermeasures leading up to ASLR, nothing else did that. Arguably, even NX didn't; NX also drastically changes exploits, but not in ways that require you to search for and stockpile memory disclosure bugs.
2. Durably increasing attacker cost has value. So: obscuring the source code for a target isn't a meaningful countermeasure; once you've reversed a target, it stays reversed. But requiring vulnerability chains for reliable mass exploitation (or even just requiring lots of engineering for each bug to obtain reliable exploitation) does make a difference. There's a reason why Chrome and iOS bugs are so expensive now.
However, it's always important to keep things in perspective. Hardware solutions to this attack would impose major performance penalties across the board, so I hope to never see them in mainstream CPUs. Software solutions to make the attack even harder to pull off might make sense for specific applications, but any ASLR implementation (either OS-wide or at the compiler level) needs to be easy to turn off.
If you're disabling ASLR over this post, please don't. Especially for performance reasons - ASLR is very very cheap, and the impact on performance tends to be in places you won't care much about.
The paper is fine, they did cool work. More importantly, ASLR is totally valid still - their attack scenario is an attacker who already can execute arbitrary code on your system, even if it's in a sandbox, which is NOT The scenario ASLR was designed to defend against.
Nothing about this attack is going to impact the effectiveness of ASLR in the cases it was designed for.
This is not the case.
ASLR is still totally viable for defending against an attacker who can not already execute arbitrary code. This article makes it sound like ASLR has been completely defeated, but it's only defeated in a context where the attacker has significant control - even if that's a likely scenario.
> Nothing about this attack is going to impact the effectiveness of ASLR in the cases it was designed for.
Then you said:
> This article makes it sound like ASLR has been completely defeated, but it's only defeated in a context where the attacker has significant control - even if that's a likely scenario.
That is indeed a highly likely scenario, so it's simply wrong to say "nothing about this attack is going to impact the effectiveness of ASLR".
I am, however, very adamant that it should remain easy to disable. Any security-performance compromise must remain under developer control, because there is no globally optimal decision on when to make which tradeoff.
"Q: How can I protect myself as a user against the AnC attack?
A: You unfortunately cannot as AnC exploits the fundamental properties of your processor. You can however stop untrusted JavaScript code from being executed on your browser using a plugin such as NoScript."
Here's a source code (not linked in paper): https://github.com/vusec/revanc
Older versions of Android don't have much protection against Stagefright or other such attacks if ASLR is circumvented. The same can apply to older versions of Windows (7 or earlier) without EMET installed.
It took the most popular desktop Linux operating systems (like Ubuntu) a very long time before they even shipped ASLR. I hope further defense in depth will be implemented now that ASLR is proven weakened.
In this project, we show that the limitations of ASLR is fundamental to how modern processors manage memory and build an attack that can fully derandomize ASLR from JavaScript without relying on any software feature.
...
Recently, browser vendors have broken the precise JavaScript timer, performance.now(), in order to thwart cache attacks. We built two new timers that bypasses this mitigation in order to make the AnC attack work.
...
Some processor vendors agreed with our findings that ASLR is no longer a viable security defense at least for the browsers.
Indeed this seems to be key here, the browser is a fairly large sandbox to play in. For "traditional" server side daemons ALSR is certainly a worthwhile layer in the security of a system.
The way they exploit the MMU page table walk is just exquisite.
Thing they could do include:
- running the javascript engine on a specific core and evicting other processes from that core, which is a common technique in real time systems (pinning and isolating);
- hardware cache partitioning, then locking PTEs and TLBs for that core (eg Intel xCAT);
- separate websites by levels of trust, and run less trusted code more conservatively. Time monotonicity can be preserved without enabling high resolution linearity.
(Intel CAT hasn't made it to the kernel mainline yet, nearly though. https://github.com/01org/intel-cmt-cat )
When you reach the point that you're trying to mitigate the effects of memory corruption, it should mean that your first N lines of defense have already failed.
>SMC builds a high-resolution counter that can be used to reliably implement AnC in all the browsers that implement it. Both Firefox and Chrome currently support this feature, but it needs to be explicit enabled due to its experimental nature. We expect shared memory between JavaScript web workers to become a default- on mainstream feature in a near future.
Note that the web workers based timer isn't required for their attack. They also discus an alternative strategy for accurate timings by looping calls to performance.now():
>The idea behind the TTT measurement, as shown in Figure 4.4, is quite simple. Instead of measuring how long a memory reference takes with the timer (which is no longer possible), we count how long it takes for the timer to tick after the memory reference takes place. More precisely, we first wait for performance.now() to tick, we then ex- ecute the memory reference, and then count by executing performance.now() in a loop until it ticks. If memory reference is a fast cache access, we have time to count more until the next tick in comparison to a memory reference that needs to be satisfied through main memory.
and it's the TTT strategy that they use against Firefox.
No javascript for you! I will not look at your ads.
* all the underlying unsafe routines are correctly implemented (unlikely in theory, false in practice)
* the compiler is correctly implemented (objectively false)
* the OS doesn't have a weird bug/hole that pwns safe programs (not very informed here, would be interested to hear examples of this)
* C libraries the Rust code FFI's into are correct (libc, openssl, gtk, etc...)
All safe languages gain defense-in-depth benefits from ASLR (insofar as anything benefits from ASLR), because our whole software stack is riddled with bugs.
The constraints are pretty small in these scenarios. Once a POC is released it becomes widespread pretty quickly. There's no special size/constraint that effectively stops this attack being run on a large scale.
Yes, there is absolutely reason to use ASLR. This attack assumes that an attacker can get the target program to eval arbitrary code. This is not something most programs do. If you are remotely exploiting a vulnerable SSH, or some service, this attack provides nothing to you. ASLR is still very effective for this use case.
This is why I find this paper so frustrating.