The idea that Rust can solve this problem is ridiculous to me. The types of bugs that sleep-deprived contributors writing fire-and-forget code will make will just shift to something that the borrow checker doesn't help with.
The factor that actually generates the bugs is the tired person writing code they will never read again or use. The borrow checker won't help with that.
I write code with different types of bugs in C, Go, Rust, Javascript, and Verilog, for example. I rarely write code with no bugs, especially when I have no real connection to the code.
If you think there's the same amount of severe exploit from software written in Go/Java/Javascript and software written in C/C++, you are just factually wrong.
70% of exploitable bugs from large company products (M$, Apple, Google) ARE memory safety bugs.
One big reason why we have so many CVEs for memory safety bugs is that they are very easy to find with analyzers and easy to programmatically test. We currently live in a world where a lot of deployed code has not had the benefit of those analyses, but the attackers do. Hence the huge number of CVEs. Rust closes that asymmetry, which is significant.
It does not mean that we won't move on to a new class of exploitable bugs that show up due to a new class of analyzers.
Also, exploitation means a lot of things to a lot of people. The fact that it's really easy to crash a Rust program could also be considered an exploit (as a number of CVEs do).
Just using Rust does not save you from exploits. Using Rust well makes it easier to be safer.
1. You acknowledge others' reports that 70% of exploitable bugs are rooted in memory safety problems.
2. You acknowledge that Rust helps reduce the number of memory safety bugs.
3. You resist any conclusion that Rust therefore reduces the number of exploitable bugs.
4. The stated reason for such resistance is "but but but they might exist and you might not know about them and something something something about how analyzers have gotten better."
1+2 alone seem like a pretty clear open & shut case to me. Your (4) looks like grasping at straw to me. You complain about "without evidence," but 1+2 looks like pretty compelling evidence to me.
One also has to wonder what kind of evidence would meet your standard. What evidence would convince you? And is that evidence even obtainable?
The evidence that would convince me is ~10 years of a notable reduction in both total CVEs and total monetary value of exploits of that software (or a comparable piece of software). There is almost nothing that would convince me today that Rust is inherently more secure than C or C++ (particularly modern C++), except in the small class of applications that rely solely on memory safety for security and cannot use a garbage collector.
By the way, I do have an application running in production today that fits that requirement, and I wrote it in Rust.
> I am also asserting that the Rust borrow checker likely won't help with those latent bugs.
Kind of a silly assertion, no? Particularly given you've failed to characterize these "latent bugs" other than the fact that they aren't related to memory safety. You've also failed to provide any compelling commentary regarding whether these "latent bugs" are present in C or C++ programs. If you believe they are, then Rust still makes the situation better by reducing the number of exploitable bugs by reducing the number of memory safety bugs.
Methinks you are suffering to an appeal to ridicule. Your comments are written as if someone is saying "Rust will eliminate exploitable bugs." Nobody has said that in this thread. More to the point, I'd be willing to wager that nobody with any modicum of credibility has ever said that.
Onto latent bugs: part of the idea of latent bugs is that they are latent, as in we don't know what they are yet. I am just pretty darn sure that we haven't found all the bugs in computer software, or even all the possible types of bugs. Spectre didn't show up until 2018, and it was a totally new type of bug.
I am pretty convinced, after working on huge-scale systems that get fuzzed really well by their clients, that we have found less than half of the exploitable bugs in Linux (and other similar systems). I'm not suggesting that Rust will hurt here, just that there's no evidence that it will. They will probably show up in C and C++ code too, but you never know.
By the way, one class of vulnerability that Rust code tends to introduce when compared to C++ code is supply chain attacks. Cargo/NPM/Pip are attack surfaces. So far, the worst version of this that I have heard about in Cargo was that several packages started printing some harmless politically-motivated text on startup.
Also, let's get this straight: I am saying that the claim "Rust reduces exploitable bugs" has not been proven yet. Let's stick to that, shall we?
I don't know how one "proves" that claim. But it definitely has enough supporting evidence to be a very reasonable belief. I certainly believe it.
I just find your entire approach here to be so strange. On the one hand, you're demanding concrete evidence, but on the other, you're waving your hands about latent bugs and quantifying the number of known bugs with zero supporting evidence.
I think this is one of those things that's common sense and you're overthinking it.
"Do static analyzers like cppcheck, Frama-C, Coverity or NASA's ikos catch more bugs (including memory bugs) than idiomatic Rust code?"
We have to consider the added complexity of the Rust language and the massive man-hours required to re-write old C code-bases. It's a trade-off.
Now, if we focus on functional properties (proving that the code is correct), one terribly hard problem when dealing with real world programs is handling the shape of the memory. That can make some proofs awful and really hard to complete. In a language like Rust, you can get a lot of information about the shape of the memory and the memory separation for free thanks to the type system. That would make proofs really easier (this is for example what is done, but with far less precision than what the Rust type system could provide, in the different memory models configuration in Frama-C/WP and it can already dramatically improve proof performance).
It probably does not justify rewrite everything, nor changing verification tools chains that are in use in some critical domains. However, I would definitely love working on and working with a Frama-Rust tool ;)
Several large surveys have found that approximately 70% of bugs in C and C++ projects are memory safety issues.
For more complex things, arguing with the borrow checker has often led me to weird solutions that seem to work, but are unlikely to be 100% bug-free.
I would also like to point out that the surveys are looking at known bugs, and memory safety bugs are now very easy to find, thanks to the large number of memory safety analyzers that exist.
The analyzers exist because memory safety problems are significant, but the fact that they are 70% of known bugs does not imply that Rust code will have 30% of the bugs that you would find in a C equivalent. In my experience, if the C equivalent is short, Rust code usually has 0% of the bugs! If the C equivalent is long and complex, it could be a lot higher.
So you're telling me you don't unit-test your code? Big red flag there!
Rust is one of the few programming languages where unit testing is an integral part of the toolset.
Mind you that Firefox, for example, has been around for 17 years. Every month I get security updates fixing multiple memory holes in the code each of which could potentially allow anyone to take over my machine. Seventeen years!! They must have fixed hundreds if not thousands of such bugs by now, and every month more are repaired by updates.
We'd have none of those had it been written in Rust.
Also mind the time saved by developers not having to hunt for such (hard to track down) bugs!
Except for memory issues in JIT-generated code from Javascript? Not all browser vulnerabilities are caused by memory safety issues in the code generated by the Javascript JIT, but several of them are (particularly "type confusion" vulnerabilities). Rust might help avoid vulnerabilities in the code generator, but not in the generated code.