[steveklabnik]

(The actual number is more than that, it’s roughly 70%. This number was reported by at least Microsoft and Chrome, among others. That roughly the same number has popped up across many large companies helps us gain confidence that it’s roughly correct, though obviously it’s not a law.)

[laumars]

The domain matters a lot here though. If you’re talking about bugs in Chrome then yeah, you’d expect it to be weighted towards buffer overflows. But if you’re taking about bugs in a build script someone has written, then I’d wager human error (given commands and have shells have a pretty esoteric syntax) are more of a problem — and certainly easier to exploit - than a buffer overflow in awk.

Don’t get me wrong, I’m all for writing stuff in safer languages (I personally haven’t touched C in years for that reason). But simply throwing Rust at the problem without assessing the risks is just as careless. In the case of most POSIX base utils, the risk isn’t buffer overflows, it’s people exposing internal tools to untrusted external users.

Take shellshock for example, that’s a prime example for just how careless people can be. And while there was patches to fix that vulnerability in Bash, people shouldn’t have been writing software that passed untrusted data to Bash in the first bloody place.

My point is: Security is a multi-layered problem. So by all means let’s pivot towards newer, safer, languages of it can remove an entire class of bugs. But let’s not pretend that rewriting the entire of POSIX in Rust is either practical nor the end of the discussion. And if we acknowledge it’s not, then we must also acknowledge there’s already things we can do to harden against our C++ utils today while those C++ utils are still a necessity.

This is why the Rust argument fucks me off. People expect too much from it and use it as an argument whenever other countermeasures should have been in place irrespective of the vulnerability that was inevitably used.