Hacker News Reader

Comment by staticassertion | Hacker News Reader

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

View on HN

I'm definitely not disabling ASLR over this post, that would be utterly silly. I've been disabling ASLR for many years in the context of specific performance-sensitive applications (mostly computational science stuff) in environments where the security concerns aren't relevant. ASLR does have a very real, measurable performance cost, but you're right in saying that it's fairly small and in most (though not all) cases you won't notice it.

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.

Developers generally can't make informed decisions about security. It should remain in developer control, I guess, but most developers have no business disabling it.

That's why it's fine to have ASLR on by default. Most developers don't even seem to be familiar with how ASLR works, and very few actively disable it in practice. Yet for some of us, the ability to do so is quite indispensable.

If you can get popped through your web browser, what's the point of taking any ASLR penalty on a desktop system?

I don't understand what you're getting at. One program is vulnerable, therefor make all programs vulnerable?

The most commonly used program with the easiest attack vector, yes. If they can get in through your browser it doesn't matter how secure the other processes were.

That makes no sense.

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

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.

Browser engines are common venues for ROP attacks. ASLR is absolutely intended to provide protection in that context.

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.

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".

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.

Reply on news.ycombinator.com