So-called "security nerds" will ignore that fact to provide a false narrative that's nothing more than FUD and misinformation.
Conversation
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.
1
1
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.
Adding in -fsanitize=unsigned-integer-overflow for full -fsanitize=integer requires going beyond just fixing bugs, since all of the intended cases of unsigned overflow need to be marked as such via no_sanitize or overflow intrinsics and benign unintended cases need to be avoided.
1
1
The best way to mark intended overflow is using the checked overflow intrinsics with the return value ignored: clang.llvm.org/docs/LanguageE. The generic variants can be wrapped into macros providing generic ops for *intentionally* wrapping arithmetic for signed and unsigned integers.
1