When invented Address Space Layout Randomization (ASLR), they already knew its weaknesses.
PaX Team knew that ASLR was likely to be an exploit mitigation of a temporary nature; that something better will (and needs to) come along.
Conversation
ASLR is meant primarily as a remote exploit mitigation, where attackers do not have access to the libs/bins.
ASLR can, in limited cases, help with local attacks, but it's not designed or meant to protect against local attacks.
1
3
That means that ASLR can't protect local attacks, even if the payload comes from a remote source. Example: Javascript in a browser.
Attacks that claim ASLR defeat by means of local code execution (like AnC) have a faulty premise: that ASLR was designed to protect these cases.
1
1
4
So-called "security nerds" will ignore that fact to provide a false narrative that's nothing more than FUD and misinformation.
1
1
Yes, ASLR is meant as a temporary measure. Yes, it has weaknesses. Yes, those weaknesses were publicly disclosed at time of invention.
This is why we at #HardenedBSD don't follow the false narrative that ASLR is the best exploit mitigation or even a security silver bullet.
3
1
2
This is why we at #HardenedBSD are pushing the envelope with CFI from #llvm.
CFI is the replacement for ASLR. I'd prefer to use RAP, but that's not possible in our case given license requirements.
3
3
Not GPL. Definitely not a GPL2-only plugin for a GPL3 software program which are incompatible licenses. A bit of a moot point anyway since it's no longer published. Probably not a great idea to use an incomplete, unmaintained old version rather than the currently maintained one.
2
1
Is that irreconcilable? Licensing stuff is something I'm not an expert on by any means, truly ignorant here.
1
OpenBSD and FreeBSD don't want to use GPL by choice, since they essentially consider it non-free. They were originally driven away from it by GPL3, which they refused to adopt, so they got stuck with old versions of GNU software, but they also don't want to use GPL2 anymore.
2
Android similarly completely avoids GPL3, and prefers only having GPL2 in the kernel with some exceptions like OpenJDK, which has a broad classpath exception. OpenBSD and FreeBSD have a much stronger stance against GPL than AOSP. License issue with those plugins is bigger anyway.
Those plugins were mostly released as GPL2, which is incompatible with GCC's GPL3 license. Some were changed to GPL2 specifically to make them incompatible with the GCC. Their theory behind that was it disallowed using it in userspace due to losing the GCC runtime exception.
1
1
Google has been using Clang-compiled kernels for a couple years and Clang CFI since last year so it's not relevant to Android. I think it's a bad idea to use the upstream Linux GCC plugins. They aren't being maintained much and I think the license issue has unclear consequences.