Hacker News new | past | comments | ask | show | jobs | submit login

I was refering to "prevents it entirely by language/compiler-level action on the target". I understand there's a whole spectrum in prevention and mitigation. But "prevents it entirely" is an extreme, just as "formally verified everything" is an extreme.

I'm just ticked off by people lately repeating that ASLR is a bandaid, like it's a bad thing. It's a bandaid, but it can still crash-instead-of-own your app/system with 99.XX% probability. Why complain about it being accepted rather than say: "great, we're nowhere near secure, but at least we have something that works most of the time, now we can work on better protection". Safe runtimes can fail too (CVE-2015-3837 / serialization bug).

Basically, if anyone reads threads like this and thinks "it's a bandaid, it's not needed / it doesn't protect me", then we're all worse off.




It's a bandaid because it covers up instead of fixed the root problems. Getting something through Softbound+CETS will stop almost all the memory errors because it tries to fix the cause. Same with pcwalton's Rust. Then, there's solutions that say leave all the problems there while trying to counter the results of an exploit in a "maybe it will work way" that are often bypassed. World of difference.

Note that using bandaids is A Good Thing if you have something broken already. It's just best to avoid what causes the breaks where possible and look for prevention measures. Our industry loves bandaids while systematically ignoring stuff that negates a need for them. So, I call out that problem but doesnt mean someone shouldnt use ASLR if it's the best bandaid they have.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: