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.
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.
1
Show replies