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
Replying to
People have argued that you shouldn't use ASAN in production. I don't know how relevant this post is today but it is worth taking into consideration: openwall.com/lists/oss-secu
1
7
Yep, this is why I wouldn't - it's not a security feature, nor a hardening measure. It's a sanitizer designed only for testing/fuzzing, and optimized for performance at the expense of correctness and safety.
1
2
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 wouldn't say that ASan sacrifices correctness but rather it's not intended to provide anything close to a form of memory safety. It isn't that it's incorrect or incomplete but that it was never supposed to do that in the first place so an attacker can bypass overflow checks.
1
Other than sequential overflows, at least, but I would recommend even using it for that...
It's entirely sensible to compile C code with instrumentation to give it coarse inter-object memory safety if you're willing to pay a huge perf cost. Not at all what ASan provides though.
1
I think that's a compelling feature. Most other people don't agree and there isn't enough interest for there to be an implementation in GCC or LLVM. There are papers about it and experimental / dangerous non-production proof of concepts but nothing actually usable / upstream yet.
Part of the problem is that it pretty much requires changing the ABI to avoid an enormous performance / memory cost. Even coarse / imprecise approximations like memory tagging require a fair bit of hardware support (ARM64 TBI - partial, ARMv8.5 MTE, SPARC ADI) to be efficient.
1
Rewriting ASan to be production / hardening oriented by eliminating all the issues with it wouldn't change that it's not a memory safety implementation but rather a heuristic way of detecting common cases of overflows. Partial temporal safety for heap also really doesn't need it.
1