3 ms·

GP comment implied there would be fewer exploitable bugs. That is definitely what happens. If you think there's the same amount of severe exploit from software

GP comment implied there would be fewer exploitable bugs. That is definitely what happens. 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.

pclmulqdq 4y ago
I do not agree with you, and I think it's a pretty strong claim to make that Rust code has fewer exploitable bugs than other code without evidence. The fact that 70% of "exploitable bugs from large company products" are memory safety bugs does not imply that those products will be any harder to exploit when re-written in Rust, just that they won't have certain types of memory safety bugs - which happen to be 70% of the known exploitable bugs that have emerged. 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.
- burntsushi 4y ago
  So let me get this straight, you're saying that: 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?
  - pclmulqdq 4y ago
    (1) is wrong. I said that 70% of reported exploitable bugs are rooted in memory safety problems. Not 70% of exploitable bugs. There is a big difference. In other words, I am suggesting that we have found a lot more of the exploitable memory safety bugs than other classes of bugs, which skews the number high, and that there are a tremendous number of latent exploitable bugs that are not related to memory safety that we haven't found out how to find yet (in a systematic way). I am also asserting that the Rust borrow checker likely won't help with those latent bugs. 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.
    - burntsushi 4y ago
      Total CVEs is a poor metric given that we (Rust programmers) tend to file CVEs far more liberally than C or C++ programmers. More to the point, the evidence you claim to require is just that: reported exploitable bugs. Which seems to have the same problems as the evidence that has already been presented to you. > 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.
      - pclmulqdq 4y ago

pclmulqdq 4y ago

I do not agree with you, and I think it's a pretty strong claim to make that Rust code has fewer exploitable bugs than other code without evidence. The fact that 70% of "exploitable bugs from large company products" are memory safety bugs does not imply that those products will be any harder to exploit when re-written in Rust, just that they won't have certain types of memory safety bugs - which happen to be 70% of the known exploitable bugs that have emerged. 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.

burntsushi 4y ago
So let me get this straight, you're saying that: 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?
- pclmulqdq 4y ago
  (1) is wrong. I said that 70% of reported exploitable bugs are rooted in memory safety problems. Not 70% of exploitable bugs. There is a big difference. In other words, I am suggesting that we have found a lot more of the exploitable memory safety bugs than other classes of bugs, which skews the number high, and that there are a tremendous number of latent exploitable bugs that are not related to memory safety that we haven't found out how to find yet (in a systematic way). I am also asserting that the Rust borrow checker likely won't help with those latent bugs. 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.
  - burntsushi 4y ago
    Total CVEs is a poor metric given that we (Rust programmers) tend to file CVEs far more liberally than C or C++ programmers. More to the point, the evidence you claim to require is just that: reported exploitable bugs. Which seems to have the same problems as the evidence that has already been presented to you. > 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.
    - pclmulqdq 4y ago