Conversation

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?)
7
8
Replying to
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
6
Replying to and
It uses instrumentation combined with features like red zones and a quarantine to detect common cases of bugs but not every case of them. It won't stop exploitation of arbitrary read/write vulnerabilities, etc. A safer approach to the quarantine can be done via malloc without it.
1
Replying to and
If the attacker knows ASan is being used, they can just bypass it for those vulnerabilities. Even if they don't, it's just an annoyance and doesn't prevent the exploitation. It would largely only defend against sequential overflows in practice. Doesn't do what most people think.
1
Replying to and
If you think what it does is providing a memory safety implementation for C that detects every case of an overflow, that's wrong. It only detects sequential overflows reliably. Everything else is basically a statistical chance to catch the overflow but not as a mitigation.
1
Replying to and
Also, it's designed to provide debugging rather than stopping execution. You can set it up to do that but just worth keeping in mind what it's designed to do is detect many common cases of bugs and provide debugging output through a complex debugging runtime tracking metadata.
1
Replying to and
It's not just that it isn't designed as a safety/security feature. It's only designed to catch common cases of bugs. It isn't a memory safety implementation and it isn't intended to catch everything. It's also not a hardened allocator. It's disabling/bypassing security features.
1