6 ms·

ASLR on the Line: Practical Cache Attacks on the MMU [pdf]

120 points by panic 10y ago

panic 10y ago
Here's a web page about it: https://www.vusec.net/projects/anc/ https://www.vusec.net/projects/anc/
kbart 10y ago
Very cool from technical perspective, but sad for web security. Takeaway for user: "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 https://github.com/vusec/revanc
jeroenhd 10y ago
This might cause a lot of infections around the world for systems without the other code execution prevention systems... 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.
youdontknowtho 10y ago
The paper says that this requires shared memory support for web workers which is an RFC. Has it actually been implemented? I can't really find any info on it.
- anon1385 10y ago
  Yes, but not enabled by default yet (and hopefully never). From the paper: >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.
j_s 10y ago
Some quotes from the summary article which is being discussed here: https://news.ycombinator.com/item?id=13648122 https://news.ycombinator.com/item?id=13648122 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.
- gbrown_ 10y ago
  > 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.
gbrown_ 10y ago
Not much to add but this paper was delightfully written and a pleasure to read.
airesQ 10y ago
This is a true tour-de-force in computer security. The way they exploit the MMU page table walk is just exquisite.
usernam 10y ago
Given there's an actual non-zero performance impact on ASLR, I wonder if there's any remaining benefit to have it (also from a maintenance perspective).
- baq 10y ago
  this result has brought the attack surface from impractically small to maybe hard but definitely reasonable; disabling ASLR altogether means reasonable becomes easy.
  - usernam 10y ago
    Given this attack can be run within large userspace programs that are run directly from the network (js via browsers, or within VM boundaries), I don't think that "reasonable" would be the right word. 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.
- staticassertion 10y ago
  The non-zero performance impact on ASLR is basically 0, and impacts link-time performance more than anything else, which most devs should not care about. So before you start going for the tiniest of microoptimizations maybe profile. 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.
keldaris 10y ago
The paper is extremely well written and their attack is very elegant, so all due credit there, however, I've never understood why ASLR was taken particularly seriously in the first place. It's always been obvious to anyone familiar with modern CPU architectures that strong ASLR is fundamentally impossible, and a vast amount of attacks have demonstrated that over time. 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.
- _pmf_ 10y ago
  ASLR is effectively security by obscurity (albeit a quite good application thereof).
  - tptacek 10y ago
    No, it's not. Security by obscurity refers to the cost increase you can inflict on an attacker by depriving them of knowledge of the design or implementation of a system. By the definition you're using, any cryptographic feature would count as "security by obscurity".
    - phkahler 10y ago
      ASLR makes it hard to know where code is located in the address space. That seems like obscurity doesn't it?
      - scienceman 10y ago
        The same way crypto obscures your text.
      - staticassertion 10y ago
        Entropy isn't obscurity.
theandrewbailey 10y ago
Another reason to not run javascript from anywhere on the internet, like ads. No javascript for you! I will not look at your ads.
phkahler 10y ago
Question: How much overlap is there between using ASLR and writing code in Rust? In other words, do the safety mechanics of Rust also prevent the kind of vulnerabilities that ASLR protects against? If so, does it do so to the extent that ASLR would be redundant for code written in rust?
- eugeneionesco 10y ago
  Rust does not protect against attacks on ASLR.
- deleted 10y ago
  [deleted]
- Gankro 10y ago
  ASLR is only relevant if you're exploiting a memory-safety bug. It is therefore "useless" in a safe Rust program (just as it's "useless" in Python, Java, JS, etc), but this is assuming: * 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.
y04nn 10y ago
If I understand correctly they are able to determine the starting address of the heap or data segment in javacscript even with ASLR. But is it useful? Do you have to exit the JS sandbox to exploit it?
- angry_octet 10y ago
  This is a component to be used in conjunction with another attack. It does the recon to determine the current memory layout. Once this is known a more traditional sandbox escape (like a content parser vulnerability) will be much more useful.
abeyer 10y ago
Great paper, but I must say that I disagree with the characterization of ASLR as "a first line of defense" in the paper, and then repeated in most of the coverage of it. 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.
angry_octet 10y ago
There are lots of things browsers can do to mitigate this, but it requires a change from the simplistic worldview of trusting a random websites javascript and assuming a software emulator won't reveal information about the host. If this paper finally prompts more concern about side channel attacks that would be great. 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 https://github.com/01org/intel-cmt-cat )
bmm6o 10y ago
Have they published the proof-of-concept code? I understand how you can use timing measurements to determine layout in theory, but what javascript statements are you running that can reveal where msvcrt.dll or kernel32.dll is loaded in chrome.exe?

120 points by panic 10y ago

panic 10y ago

Here's a web page about it: https://www.vusec.net/projects/anc/ https://www.vusec.net/projects/anc/

kbart 10y ago

Very cool from technical perspective, but sad for web security. Takeaway for user: "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 https://github.com/vusec/revanc

jeroenhd 10y ago

This might cause a lot of infections around the world for systems without the other code execution prevention systems... 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.

youdontknowtho 10y ago

The paper says that this requires shared memory support for web workers which is an RFC. Has it actually been implemented? I can't really find any info on it.

anon1385 10y ago
Yes, but not enabled by default yet (and hopefully never). From the paper: >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.

j_s 10y ago

Some quotes from the summary article which is being discussed here: https://news.ycombinator.com/item?id=13648122 https://news.ycombinator.com/item?id=13648122 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.

gbrown_ 10y ago
> 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.

gbrown_ 10y ago

Not much to add but this paper was delightfully written and a pleasure to read.

airesQ 10y ago

This is a true tour-de-force in computer security. The way they exploit the MMU page table walk is just exquisite.

usernam 10y ago

Given there's an actual non-zero performance impact on ASLR, I wonder if there's any remaining benefit to have it (also from a maintenance perspective).

baq 10y ago
this result has brought the attack surface from impractically small to maybe hard but definitely reasonable; disabling ASLR altogether means reasonable becomes easy.
- usernam 10y ago
  Given this attack can be run within large userspace programs that are run directly from the network (js via browsers, or within VM boundaries), I don't think that "reasonable" would be the right word. 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.
staticassertion 10y ago
The non-zero performance impact on ASLR is basically 0, and impacts link-time performance more than anything else, which most devs should not care about. So before you start going for the tiniest of microoptimizations maybe profile. 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.

keldaris 10y ago

The paper is extremely well written and their attack is very elegant, so all due credit there, however, I've never understood why ASLR was taken particularly seriously in the first place. It's always been obvious to anyone familiar with modern CPU architectures that strong ASLR is fundamentally impossible, and a vast amount of attacks have demonstrated that over time. 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.

_pmf_ 10y ago
ASLR is effectively security by obscurity (albeit a quite good application thereof).
- tptacek 10y ago
  No, it's not. Security by obscurity refers to the cost increase you can inflict on an attacker by depriving them of knowledge of the design or implementation of a system. By the definition you're using, any cryptographic feature would count as "security by obscurity".
  - phkahler 10y ago
    ASLR makes it hard to know where code is located in the address space. That seems like obscurity doesn't it?
    - scienceman 10y ago
      The same way crypto obscures your text.
    - staticassertion 10y ago
      Entropy isn't obscurity.

theandrewbailey 10y ago

Another reason to not run javascript from anywhere on the internet, like ads. No javascript for you! I will not look at your ads.

phkahler 10y ago

Question: How much overlap is there between using ASLR and writing code in Rust? In other words, do the safety mechanics of Rust also prevent the kind of vulnerabilities that ASLR protects against? If so, does it do so to the extent that ASLR would be redundant for code written in rust?

eugeneionesco 10y ago
Rust does not protect against attacks on ASLR.
deleted 10y ago
[deleted]
Gankro 10y ago
ASLR is only relevant if you're exploiting a memory-safety bug. It is therefore "useless" in a safe Rust program (just as it's "useless" in Python, Java, JS, etc), but this is assuming: * 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.

y04nn 10y ago

If I understand correctly they are able to determine the starting address of the heap or data segment in javacscript even with ASLR. But is it useful? Do you have to exit the JS sandbox to exploit it?

angry_octet 10y ago
This is a component to be used in conjunction with another attack. It does the recon to determine the current memory layout. Once this is known a more traditional sandbox escape (like a content parser vulnerability) will be much more useful.

abeyer 10y ago

Great paper, but I must say that I disagree with the characterization of ASLR as "a first line of defense" in the paper, and then repeated in most of the coverage of it. 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.

angry_octet 10y ago

There are lots of things browsers can do to mitigate this, but it requires a change from the simplistic worldview of trusting a random websites javascript and assuming a software emulator won't reveal information about the host. If this paper finally prompts more concern about side channel attacks that would be great. 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 https://github.com/01org/intel-cmt-cat )

bmm6o 10y ago

Have they published the proof-of-concept code? I understand how you can use timing measurements to determine layout in theory, but what javascript statements are you running that can reveal where msvcrt.dll or kernel32.dll is loaded in chrome.exe?