Not at all since the only issues it finds reliably are linear overflows. It can't detect temporal safety issues when allocations are out of the quarantine and can't detect most out-of-bounds accesses but rather only special cases. It can't detect anything within objects either.
Conversation
Sure they aren’t the same but not that different either. The tools available for “memory unsafe” languages (like asan, valgrind) catch the vast majority of memory bugs. Acting like it’s the wild wild west for C/C++ is silly.
1
They detect memory corruption when it occurs at runtime not the presence of the memory corruption bugs. If the current usage of the program doesn't trigger memory corruption with those bugs, there's nothing for them to detect. They're far from detecting the vast majority of them.
1
In almost any mature program, the vast majority of memory corruption bugs will be latent issues not actually corrupting memory between objects during regular usage. ASan only detects memory corruption when it occurs, only between objects (not within) and nowhere close to all.
2
Do you have data to back this up? This has not been my experience.
1
The vast majority of my memory bugs have to do with pointer invalidation (like access after a realloc)
1
Finding bugs with ASan during regular usage / testing is a demonstration of the program having memory corruption bugs to the point that the bugs are corrupting memory during regular use, not just adversarial conditions. It's not relevant data or experience with this at all.
1
I can boot up AOSP and open Chromium to example.org with the kernel, userspace and browser compiled with ASan. There are no bugs detected. I can run a substantial portion of the massive CTS with none detected. Rate memory corruption bugs are found has not gone down.
1
Linux kernel is tested quite a bit with ASan these days and yet somehow there are hundreds of memory corruption bugs found every month on the SAME configurations that are tested ranging from ancient decades old ones to new ones. Flow of discoveries is accelerating not slowing.
2
Even after writing great domain-specific fuzzers to use with ASan, clearly there are still a massive amount of edge cases triggering memory corruption that are left undiscovered. ASan can only find what actually happens at runtime, and as stated above, only a subset of that.
1
The statistics for major real world open source projects where security research is actually done in any significant way would be totally impossible if you could find most memory corruption bugs by simply running the program in ASan through regular usage or their test suites.
ASan is not a hardening tool and is trivially bypassed in adversarial situations for anything but a linear overflow. HWAsan is a lot closer to something that could be a viable hardening tool, but the actual implementation of that is MTE and is not anywhere close to memory safety.
1
The Tor Browser deployed ASan in production based on that misunderstanding of what it does and then had to back that out due to it actually making things worse in many ways. It's not memory safety, and an attacker who detects it can actually more easily exploit vulnerabilities.