>"A major part of my career has been to write these tools. There's a reason why none of them are sound."
This is an interesting take coming from a person who writes the tools. Obviously you know way more about it. I do understand that if I for example link ASAN and it does not show errors for a while it is not a guarantee. The software just might not hit that error path. But I am a practical man running my own company and can not be a perfectionist. If software passes my own test, analyzers and other tools do not report anything suspicious and I have no bug reports from a customer I can sleep well and count my money ;)
>"You might belong to the rarified class of uber-developers who can write bug-free C++ applications"
I absolutely do not write bug free applications but I tend to have very few to begin with and I do eradicate them pretty fast. Some of my stable releases run for years without any bug related complaints. Not sure if that qualifies for "uber". I am however very good architect and deliver solutions in very diverse areas. Desktop, multimedia, enterprise backends, middleware, device control firmware etc. Also understand electronics.
I'm on the static side. The sanitizers are indeed great tools but they are mostly too performance-costly to run in production environments, so they just exist for your tests and maybe for some small percentage of your production environment. Deployed in this manner, it isn't going to catch everything.
I think that asan is also theoretically unsound (I don't know its innards well enough) based on how it actually tags pages but in practice this isn't super relevant. The question is whether you actually execute the problematic sequence in some build that has asan enabled.
> Not sure if that qualifies for "uber".
Writing C++ code with minimal memory errors would qualify as "uber", given the data available from both academic and industrial research on C++ application development. The data is very clear - real applications run into these issues with frequency even when they consistently use modern smart pointers.
Current project (business backend server in C++) that would qualify for attack sits behind NGINX. Looking at the logs I see all kinds of attempts related to Wordpress, PHP, etc. etc. Also we use 3rd party protection on production before NGINX.
Since the server exposes proprietary JSON API with what I would say extreme validation before trying to actually do anything nothing that seems to be illegal gets in.
I mean it is not 100% guarantee as nothing else in our lives but so far nothing extraordinary (keeping my fingers crossed).
if you see it in the logs, that seems like bots looking for low hanging fruit. what about focused attacks by sophisticated adversaries? here, a heap buffer overflow in a c++ library is a major part of enabling rce https://en.wikipedia.org/wiki/Xpdf
This is an interesting take coming from a person who writes the tools. Obviously you know way more about it. I do understand that if I for example link ASAN and it does not show errors for a while it is not a guarantee. The software just might not hit that error path. But I am a practical man running my own company and can not be a perfectionist. If software passes my own test, analyzers and other tools do not report anything suspicious and I have no bug reports from a customer I can sleep well and count my money ;)
>"You might belong to the rarified class of uber-developers who can write bug-free C++ applications"
I absolutely do not write bug free applications but I tend to have very few to begin with and I do eradicate them pretty fast. Some of my stable releases run for years without any bug related complaints. Not sure if that qualifies for "uber". I am however very good architect and deliver solutions in very diverse areas. Desktop, multimedia, enterprise backends, middleware, device control firmware etc. Also understand electronics.