Question for Rust people: when you use a C library, and you write a safe interface around it, is it common to build that C library with AddressSanitizer? (if not, why not?)
Conversation
I build and test as much code as possible with asan+ubsan. I've found too many bugs in both my code and libraries to trust code review of unsafe programming. But deploying with asan? If I'm willing to trade off that much performance for safety something has gone seriously awry.
1
Quote Tweet
Replying to @kripken
ASan isn't designed for providing safety / hardening and doesn't do a good job of mitigating vulnerabilities. It also adds extra attack surface and may make you worse off than not using it. It's not a memory safety implementation for C. It's a way to detect common cases of bugs.
1
I've heard this before, but I've heard of canaries running with sanitizers. Has anyone demonstrated exploiting those?
1
The issue is mostly that people misunderstand it to be a hardening measure rather than it introducing new ways to do exploitation. It does screw up assorted mitigations and doesn't actually provide safety against overflows, etc. though other than special cases like sequential.
1
Also doesn't even do that if you don't configure it a specific way to kill the process when it detects something. It's designed around using a complex debugging runtime generating usable tracebacks etc. and just spewing stuff to logs. Only meant to catch common overflow cases.
1
i.e. designed to have a decent chance that the overflow happens in a way that it can detect it. If an attacker is doing it, they can bypass it. It doesn't outright catch arbitrary read, arbitrary write, etc. but rather OFTEN catches it since it hits red zones / different stuff.
1
I totally get that asan's redzones can be jumped over, and thus the interest in memory tagging.
But have there been demonstrations of asan making things _worse_? I'm just curious. Totally understand the other reasons why it doesn't make sense to deploy.
1
openwall.com/lists/oss-secu is one set of examples.
It doesn't go into how ASan bypasses existing mitigations like ASLR, hardened allocators, etc. It is also incompatible with a lot of mitigations due to how it uses the address space by reserving at a static address, etc.
1
reviews.llvm.org/D70958 and so on. It's not just incompatible with ASLR but also stronger mitigations where the way it uses address space especially dependence on reserving a specific static range of addresses isn't compatible.
If it was actually a memory safety implementation then being incompatible with ASLR, hardened allocators and various other mitigations would be worthwhile - but that's not what it actually provides, and it's probably not a good trade for what ASan actually provides.
1
Also has the issues stemming from it just being heavily debug oriented and not really designed to be used in production or to respect the security model and security features. It's a great debug feature but the way it works and how it's implemented is honestly kinda horrific.