4 ms·
> 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
by 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 agoWhat? 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 agoBrowser engines are common venues for ROP attacks. ASLR is absolutely intended to provide protection in that context.
- staticassertion 10y agoASLR 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 agoYou'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 agoNot 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.
- loeg 10y agoIf you can get popped through your web browser, what's the point of taking any ASLR penalty on a desktop system?
- staticassertion 10y agoI don't understand what you're getting at. One program is vulnerable, therefor make all programs vulnerable?
- loeg 10y agoThe 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.
- staticassertion 10y agoThat makes no sense.
- keldaris 10y agoI'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.
- staticassertion 10y agoDevelopers generally can't make informed decisions about security. It should remain in developer control, I guess, but most developers have no business disabling it.
- keldaris 10y agoThat'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.