4 ms·

> 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 desi

> 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.
    - ghughes 10y ago
      You've contradicted yourself. You initially said: > 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".
      - staticassertion 10y ago
        Not really seeing the contradiction. ASLR is still effective where it was always intended to be effective. ASLR is ineffective given an attacker with more control than ASLR was designed to be useful against.

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.
  - ghughes 10y ago
    You've contradicted yourself. You initially said: > 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".
    - staticassertion 10y ago
      Not really seeing the contradiction. ASLR is still effective where it was always intended to be effective. ASLR is ineffective given an attacker with more control than ASLR was designed to be useful against.