7 ms·

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 se

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.
      - phkahler 10y ago
        I like this clarification the best.
    - mikeash 10y ago
      The term is somewhat more restricted than its literal meaning would imply. "Security through obscurity" specifically refers to obscurity in the design or implementation of a system. Obscuring explicitly secret values used by the system is not "security through obscurity." 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.
    - wolf550e 10y ago
      "security through obscurity" refers only to violations of Kerckhoffs's principle. https://en.wikipedia.org/wiki/Kerckhoffs's_principle https://en.wikipedia.org/wiki/Kerckhoffs's_principle
- rocqua 10y ago
  No, the 'algorithm' for ASLR is public. All that an attacker is missing is the seed that determines how it is instantiated. ASLR doesn't violate Kerckhoffs' principle.
tptacek 10y ago
Two responses, one specific and one general. 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.
- keldaris 10y ago
  I agree, on both counts. For some applications (web browsers top that list nowadays) ASLR has a lot of demonstrable value as a mitigation measure. I could easily imagine security-critical systems where even proper strong ASLR (with randomized page tables or even fundamentally different caching and MMUs) would make sense. 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.
staticassertion 10y ago
> I'm just happy it's easy to disable for performance reasons 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.
- lawnchair_larry 10y ago
  > 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.
  - staticassertion 10y ago
    What? Which part is not the case? This attack does require executing arbitrary JS on the victim system. This attack is not viable if you're exploiting some RCE against a C program that doesn't evaluate code.
    - ghughes 10y ago
      Browser engines are common venues for ROP attacks. ASLR is absolutely intended to provide protection in that context.
      - staticassertion 10y ago
        ASLR is a mitigation for ROP given certain constraints - the ability to arbitrarily execute code, allocate memory, would break those constraints. This is true of any mitigation technique, there are capabilities an attacker can have that will make it less relevant or irrelevant. 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.

_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.
    - phkahler 10y ago
      I like this clarification the best.
  - mikeash 10y ago
    The term is somewhat more restricted than its literal meaning would imply. "Security through obscurity" specifically refers to obscurity in the design or implementation of a system. Obscuring explicitly secret values used by the system is not "security through obscurity." 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.
  - wolf550e 10y ago
    "security through obscurity" refers only to violations of Kerckhoffs's principle. https://en.wikipedia.org/wiki/Kerckhoffs's_principle https://en.wikipedia.org/wiki/Kerckhoffs's_principle
rocqua 10y ago
No, the 'algorithm' for ASLR is public. All that an attacker is missing is the seed that determines how it is instantiated. ASLR doesn't violate Kerckhoffs' principle.

tptacek 10y ago

Two responses, one specific and one general. 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.

keldaris 10y ago
I agree, on both counts. For some applications (web browsers top that list nowadays) ASLR has a lot of demonstrable value as a mitigation measure. I could easily imagine security-critical systems where even proper strong ASLR (with randomized page tables or even fundamentally different caching and MMUs) would make sense. 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.

staticassertion 10y ago

> I'm just happy it's easy to disable for performance reasons 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.

lawnchair_larry 10y ago
> 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.
- staticassertion 10y ago
  What? Which part is not the case? This attack does require executing arbitrary JS on the victim system. This attack is not viable if you're exploiting some RCE against a C program that doesn't evaluate code.
  - ghughes 10y ago
    Browser engines are common venues for ROP attacks. ASLR is absolutely intended to provide protection in that context.
    - staticassertion 10y ago
      ASLR is a mitigation for ROP given certain constraints - the ability to arbitrarily execute code, allocate memory, would break those constraints. This is true of any mitigation technique, there are capabilities an attacker can have that will make it less relevant or irrelevant. 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.