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.
Conversation
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
Note that both SafeStack and Cross-DSO CFI from LLVM require both ASLR and NOEXEC for proper efficacy.
They both store important metadata needing protections.
1
So one could argue that bypassing Cross-DSO CFI and SafeStack might also be one infoleak away, but attackers would also need to chain an additional data-only attack along with their original exploit payload.
1
So, no longer can applications be exploited "point-n-click" style, where the payload is copy/pasted verbatim to attack multiple hosts with 100% reproducibility and accuracy.
1
#HardenedBSD is the only fully open source enterprise OS making significant use of CFI and SafeStack for userland.
We're pushing the state-of-the-art security forward.
2
2
7
I'm pretty sure that #NetBSD and #OpenBSD likely will follow suit. NetBSD seems to be making larger use of the llvm sanitizer framework than any of the other BSDs, #HardenedBSD included.
ASAN, UBSAN, TSAN, MSAN, etc. are meant as debugging tools, not exploit mitigations, though.
2
1
2
Replying to
UBSan is a special case, since it can be used in the trapping mode without a runtime for production usage. Some of the UBSan sanitizers are quite useful as exploit mitigations in trapping mode. It also offers more than just detection of undefined behavior with some extensions.
Android makes extensive usage of -fsanitize=integer -fsanitize-trap=integer for hardening in production, particularly in media libraries. That includes integer sanitizers included in -fsanitize=undefined along with -fsanitize=unsigned-integer-overflow.
clang.llvm.org/docs/Undefined
1
1
Using these without -fsanitize=unsigned-integer-overflow included requires fixing a lot of bugs, many of them benign but still undefined. Extensions can make it easier, since the overflow intrinsics offer well-defined signed overflow when it's actually intentional.
1
1
Show replies