14 ms·

> All languages have CVEs, C++ just has more (and C still more); so far in 2024, Rust has 6 CVEs [1], and C and C++ combined have 61 CVEs [2]. So zero isn’t the

> All languages have CVEs, C++ just has more (and C still more); so far in 2024, Rust has 6 CVEs [1], and C and C++ combined have 61 CVEs [2]. So zero isn’t the goal; something like a 90% reduction is necessary, and a 98% reduction is sufficient, to achieve security parity with the levels of language safety provided by MSLs The author is making a massive assumption that all CVEs are equally serious but they aren't. Opening the Rust links indicates several of them are denial of service, including regular expression denial of service. Not downplaying this, but compare it to the first result in the other link, which involves potential remote code execution (RCE). Take for example CVE-2022-21658 (https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html) in Rust, related to a filesystem API. It's true, this was a CVE in Rust and not a CVE in C++, but only because C++ doesn't regard the issue as a problem at all. The problem definitely exists in C++, but it's not acknowledged as a problem, let alone fixed. That's why counting CVEs alone is meaningless. The author concedes that CVEs are not a good metric to measure by, but implies that maybe C and C++ have too many CVEs that shouldn't actually be CVEs and that the C++ community should take more control of CVEs being filed. This is ominous, and makes me fear we might start to see fewer C and C++ CVEs because issues will be closed as "intended behaviour" or "won't fix", like the filesystem issue above. [1] - https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust [2] - https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=c++ https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=c++

criddell 3y ago
His 98% figure sounds about right, doesn’t it? Eliminate 98% of C++ CVEs and that’s enough to compete with memory safe languages.
- nindalf 3y ago
  Except the CVEs in Rust are far more likely to be low severity issues that C++ would never acknowledge to begin with.
  - sirwhinesalot 3y ago
    It would still be worthwhile to greatly reduce the number of vulnerabilities coming out of new C and C++ code, which are likely to be with us for a long time still. At the very least as updates/fixes to existing codebases.
    - nindalf 3y ago
      Yes, no doubt - reducing the number of vulnerabilities is a good thing. What I'm worried about is that they merely reduce the number of CVEs, and call it a win for their safety initiative. It becomes a PR exercise more than technological improvement.
      - humanrebar 3y ago
        Well, pay attention and hold them accountable. But Microsoft (for instance) certainly has incentives to avoid being the next Boeing or Volkswagen with respect to being excellent box checkers that end up missing the mark on the outcomes those checkboxes are supposed to protect against. It doesn't matter if C and C++ have fewer CVEs as such if Microsoft tools and platforms gain a reputation as being insecure or unsafe.
- lifthrasiir 3y ago
  Sounds about right because he is using the number of eliminated CVEs, not the number of remaining CVEs. Compare with 98% and 99.8%; even when we have been tracking all possible CVEs, 98% elimination will leave 10x remaining CVEs than 99.8% elimination. (Of course both are much better than 0% elimination, i.e. status quo.) I feel the true figure would be somewhere around 99.8% and 99.98%, especially when a massive undercount from existing C/C++ projects is accounted for.
  - humanrebar 3y ago
    He addresses this point in the article as well, discussing risks that that language community gets too fixated on one kind of safety while attackers shift to other concerns like supply chain, code injection, or leaked credentials.
    - lifthrasiir 3y ago
      Of course, but memory unsafety is one of the biggest enabler for security vulnerabilities. Attackers have shifted to other concerns when PHP became widespread enough for example, but PHP alone cannot be used to create a vulnerability common in C/C++ because of its memory safety (which is not even that good!), you need some other systems to combine multiple issues into a single coherent attack, and it's likely that C/C++'s memory unsafety has played a great role somewhere in between. He doesn't fully acknowledge this multiplicative aspect of memory (un)safety.
    - saghm 3y ago
      That sounds like a situation I'd describe as "a good problem to have". Almost completely eliminating a comment attack vector and having to figure out how to pivot to stamp out another type is far better than just not making any significant progress at all. If the concern were that they were already making progress on some of those other security concerns and they were worried that switching focus would risk gains they expect to make soon in those areas, I think that would be reasonable, but that doesn't seem to be the case. Is there any evidence that this concern is anything other than hypothetical? It comes across more as an attempt to justify not spending effort improving memory safety rather than something that anyone is actually concerned about.
- saagarjha 3y ago
  Absolutely not. Software that has 98% fewer memory safety issues is…still exploited. People just look harder and the costs go up a bit.
  - TomSwirly 3y ago
    No, there is in fact a qualitative difference between a program where the expected number of CVEs is 1, and one where the expected number of CVEs is 0.02.
    - saagarjha 3y ago
      Yes, there are fewer CVEs. So?
      - oasisaimlessly 3y ago
        Are you being purposely dense? If the mean number of CVEs is low enough, some proportion of software has 0 exploitable flaws, and is invulnerable regardless of how much attackers spend.
        saagarjha 3y ago
        I consider that most software that people use is sufficiently complex enough that it will not fall in this bucket.
- saghm 3y ago
  Is aiming for exact parity the best way to achieve that though? I'm skeptical that memory safe languages have 98% fewer CVES than C++ because their goal wass "have 2% of the CVEs that C++ has" and they succeeded and not "try to have no CVEs whatsoever" and they failed by a small amount.
- pizlonator 3y ago
  But how do you know that the language has eliminated 98% of vulnerabilities? 98% of what? CVEs? Something else?
- pjdesno 3y ago
  The most recent data I could find, from 2019, shows that 17% of CVEs are in PHP code, 12% in Java, and 11% in JavaScript - all memory-safe languages. Memory safety bugs are only one class of security vulnerabilities, and there's nothing magical about memory safeness that causes a developer using that language to suddenly become expert at writing secure code. For that matter, some vulnerabilities actually seem much more common in memory-safe languages - try searching the CVE database for "SQL injection c++" (287 results) vs javascript (3420), Java (2160), or PHP (11300).
humanrebar 3y ago
Or you can flip it around and ask why there isn't a body in the C and C++ community funding tangible advancements in the security and safety problem space the way the Python Foundation and Rust Foundation are.
- nindalf 3y ago
  I don't know about this. There are a lot of people being paid by their companies to work on the C++ committee and on various compiler teams. The author of the post we're discussing is a member of the committee and this article is an attempt to improve the security situation in C++. So funding isn't the issue. The issue is that the committee has a firm commitment to never introducing breaking changes. This commitment is so firm that it trumps literally any other interest, like making the language memory safe. That's why the author only suggests non-breaking changes in this article. Lots of people are going to have opinions on whether this approach is the right one for C++'s long term success, but I think we'll only know in 5-10 years.
  - cesarb 3y ago
    > That's why the author only suggests non-breaking changes in this article. One of the proposals in the article is to change the meaning of things like "if (a != b > c)" and "if (0 <= index < max)". That changes program behavior and therefore is a breaking change (for instance, the code might accidentally be depending on the "wrong" results of these odd comparisons, and "fixing" them makes it go through an untested path which does the wrong thing).
    - jcelerier 3y ago
      It's ok if the current behaviour is changed into a compiler error
      - cesarb 3y ago
        I agree; while changing it into a compiler error could be considered "breaking" (it no longer compiles), it's not a silent break and forces the developer to fix the code. (I would only worry about developers doing the "obvious" fix to shut the compiler up without looking at the surrounding code to see if it was masking some other bug.)
adev_ 3y ago
> Take for example CVE-2022-21658 (https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html) in Rust, related to a filesystem API. It's true, this was a CVE in Rust and not a CVE in C++, but only because C++ doesn't regard the issue as a problem at all. That just plain wrong. Just simply wrong. And I hope it is not a lie done on purpose. The C++ community acknowledge the issue as soon as the Rust one posted the problem and issued a fix which is already deployed with major compilers [^1] [^2] It does not have a CVE associated since the issue was spotted within Rust stdlib first. This is this exact kind of FUD and zealotism that makes people hate the Rust community. I wish the community mature a bit on this aspect. [^1]: https://github.com/gcc-mirror/gcc/commit/ebf6175464768983a2d8c82c2d47771ee89192b8 https://github.com/gcc-mirror/gcc/commit/ebf6175464768983a2d... [^2]: https://github.com/llvm/llvm-project/commit/4f67a909902d8ab9e24e171201db189b661700bf https://github.com/llvm/llvm-project/commit/4f67a909902d8ab9...
- nindalf 3y ago
  > It does not have a CVE associated since the issue was spotted within Rust stdlib first. I don't see why this is true. Are you saying that people with affected code would have seen a Rust CVE and then updated their C++ toolchains? There seems to be no reason this shouldn't have been a C++ CVE other than the fact that C++ community has different standards for what constitutes safety. The lack of CVE associated with the fixes you pointed out support the original assertion rather than refuting it. In fact, I'll tell you why there was no CVE for C++ - concurrent access to filesystem APIs is undefined behaviour in C++ (https://en.cppreference.com/w/cpp/filesystem https://en.cppreference.com/w/cpp/filesystem). Reasonable people can disagree on this though, so I can see where you're coming from. There's no reason to immediately fling around accusations of lying and zealotry. It makes the writer look immature.
  - adev_ 3y ago
    > There seems to be no reason this shouldn't have been a C++ CVE other than the fact that C++ community has different standards for what constitutes safety A security report has been filed for both compiler and actions taken for both of the major toolchain. This is a sign of mature security processes in used by both of the major C++ compiler implementations. CVE are one among many way to address security vulnerabilities, one way that is currently heavily under criticism [^1] > In fact, I'll tell you why there was no CVE for C++ - concurrent access to filesystem APIs is undefined behaviour in C++ The vulnerability reported (even in case of the Rust CVE) has nothing to do with a concurrent usage of the API. I think you do not really know what you are talking about here. > Reasonable people can disagree on this though, so I can see where you're coming from. There's no reason to immediately fling around accusations of lying and zealotry. It makes the writer look immature. My definition of immature includes the fact of throwing false statement over the internet, getting them refuted with sources and quote included. And still stance on them. This is a sign of immaturity. [^1]: https://portswigger.net/daily-swig/cvss-system-criticized-for-failure-to-address-real-world-impact https://portswigger.net/daily-swig/cvss-system-criticized-fo...
pornel 3y ago
The CVE/CVSS system lacks ability to deal with soundness issues. If the language or a library promises to catch a mistake, and it doesn’t, that’s not automatically exploitable unless the programmer has actually made that mistake. If there wasn’t a promise in the first place, there would be nothing to report. Unfortunately, CVE can’t see the difference between reporting a bug, or reporting a theoretical possibility of having a bug that never actually happened.
- mattgreenrocks 3y ago
  Frankly, I don't think industry is going to allow soundness issues to ever achieve parity of importance with what we think of as CVEs. There's simply too much code and mindshare around languages that don't worry as much about soundness. I'm not saying it is right, just that concerns around soundness will likely be hand-waved away. And it is to everyone's detriment.
deleted 3y ago
[deleted]
kllrnohj 3y ago
> It's true, this was a CVE in Rust and not a CVE in C++, but only because C++ doesn't regard the issue as a problem at all. The problem definitely exists in C++, but it's not acknowledged as a problem, let alone fixed. Can you find a link that substantiates your claim? You're throwing out some heavy accusations here that don't seem to match reality at all. Case in point, this was fixed in both major C++ libraries: https://github.com/gcc-mirror/gcc/commit/ebf6175464768983a2d8c82c2d47771ee89192b8 https://github.com/gcc-mirror/gcc/commit/ebf6175464768983a2d... https://github.com/llvm/llvm-project/commit/4f67a909902d8ab9e24e171201db189b661700bf https://github.com/llvm/llvm-project/commit/4f67a909902d8ab9... So what C++ community refused to regard this as an issue and refused to fix it? Where is your supporting evidence for your claims?
- nindalf 3y ago
  I stand corrected that the issue wasn't fixed (https://news.ycombinator.com/item?id=39680006 https://news.ycombinator.com/item?id=39680006). The issue was fixed, but no CVE by the C++ libraries. That reinforces the point that the author's attempt to equate 1 Rust CVE = 1 C++ CVE isn't valid.
- kouteiheika 3y ago
  > Can you find a link that substantiates your claim? You're throwing out some heavy accusations here that don't seem to match reality at all. Relevant piece of the standard: http://eel.is/c++draft/fs.race.behavior#1.sentence-2 http://eel.is/c++draft/fs.race.behavior#1.sentence-2 Officially it's undefined behavior. And here's a comment from the maintainer of the STL in MSVC regarding this: https://old.reddit.com/r/cpp/comments/151cnlc/a_safety_culture_and_c_we_need_to_talk_about/js8m9sp/ https://old.reddit.com/r/cpp/comments/151cnlc/a_safety_cultu...
  - kllrnohj 3y ago
    That statement really doesn't support your claim and unsurprisingly Rust has the same basic caveat because of course it does, it's not possible for a language to guarantee exclusive IO access to the filesystem. https://doc.rust-lang.org/std/io/index.html#io-safety https://doc.rust-lang.org/std/io/index.html#io-safety
saghm 3y ago
Not to mention the weird conclusion that since no language has 0, that isn't the goal. I'm not sure I understand the logic that you shouldn't at least _try_ to not have any major security flaws. My interpretation of the CVE counts he mentions is that if your goal is zero, you might end up still having a few, but if your goal is just "few enough that people stop complaining about us being worse than other languages in a similar niche", you probably will end up not hitting that threshold either, which seems like a plausible explanation for how C++ is in this situation in the first place. The fact that he brings up C a bunch also seems like it could be related to this; it sort of feels like he's focusing too much on the idea of security as a competition between languages rather than something that's inherently worthwhile as a goal in its own right.
- kllrnohj 3y ago
  The point is that trying to hit 0 would be a huge breakage that would fragment the language, and there's no actual evidence to suggest such a thing is actually necessary. It's like your front door's lock. It doesn't have to be unpickable, unshimmable, absolutely secure. It just has to put up more of a fight than a brick through the window.
  - jvanderbot 3y ago
    Yep yep. A better analogy might be that the door has to eliminate quick, quiet entry to the house since that would deter a huge majority of would-be burglars just due to the vastly increased danger of getting noticed. We have locks on windows, but rarely bars. We have alarms that trigger sirens, but rarely indoor locks. Eliminate quick and quiet, usually good enough.
  - saghm 3y ago
    I think the problem with this analogy for me is that while you might not care to have your home be 100% impossible to break into, you _do_ want to aim for it to be broken into zero times a year. If my house got broken into 60 times a year for five years, and my neighbors got broken into 6 times a year for the same period, I still think my long-term goal would be to have my home _never_ broken into, even if it meant moving to a different neighborhood.
cozzyd 3y ago
What if you normalize for the amount of code in the wild? Relatively little software I use day to day have significant amounts of rust in them (only Firefox and my phone OS, probably...). Even in firefox, there is far more C++ than rust...
- steveklabnik 3y ago
  You’d also have to define what “use” means. Your traffic that goes through Cloudflare hits Rust code: does that count as a “use”? Sites you use that rely on AWS almost certainly hits Rust code, does that count as a “use”? I think it’s kind of stretching it, but these are services where issues in them could impact you, so I don’t think it’s a total non sequitur.
  - cozzyd 3y ago
    that's totally fair, certainly there are web servers I use that are probably using rust somewhere, but I suspect it's still a relatively small amount of code (even if widely used!).
  - fch42 3y ago
    This is true - and also misses one of the points Herb Sutter's article is making. I don't disagree at all with what seems the general sentiment here about the importance of memory safety. I also, though, don't disagree with Herb Sutter that there are other safety-relevant aspects in both programming and software deployment which aren't helped/prevented "merely" by using memsafe languages. Say, the "typical" rust laziness ... just unwrap() because well we know for sure it can't possibly be None, right ? Do that in a form of crit code path, and while that may not open you to an exploit, it'll still down your service and damn you to a crashloop. Yes, we should be using memsafe languages. Yes, we should be a little humble about bugs we may create. As important as it is to entirely eliminate one "critical" class, as important it is to realize even with that gone, bugs/issues/security problems will remain.
    - steveklabnik 3y ago
      > As important as it is to entirely eliminate one "critical" class, as important it is to realize even with that gone, bugs/issues/security problems will remain. Sure. Nobody believes that memory safety is the sole security issue. Or at least, no serious people, or any of the organizations doing advocacy around this issue.

criddell 3y ago

His 98% figure sounds about right, doesn’t it? Eliminate 98% of C++ CVEs and that’s enough to compete with memory safe languages.

nindalf 3y ago
Except the CVEs in Rust are far more likely to be low severity issues that C++ would never acknowledge to begin with.
- sirwhinesalot 3y ago
  It would still be worthwhile to greatly reduce the number of vulnerabilities coming out of new C and C++ code, which are likely to be with us for a long time still. At the very least as updates/fixes to existing codebases.
  - nindalf 3y ago
    Yes, no doubt - reducing the number of vulnerabilities is a good thing. What I'm worried about is that they merely reduce the number of CVEs, and call it a win for their safety initiative. It becomes a PR exercise more than technological improvement.
    - humanrebar 3y ago
      Well, pay attention and hold them accountable. But Microsoft (for instance) certainly has incentives to avoid being the next Boeing or Volkswagen with respect to being excellent box checkers that end up missing the mark on the outcomes those checkboxes are supposed to protect against. It doesn't matter if C and C++ have fewer CVEs as such if Microsoft tools and platforms gain a reputation as being insecure or unsafe.
lifthrasiir 3y ago
Sounds about right because he is using the number of eliminated CVEs, not the number of remaining CVEs. Compare with 98% and 99.8%; even when we have been tracking all possible CVEs, 98% elimination will leave 10x remaining CVEs than 99.8% elimination. (Of course both are much better than 0% elimination, i.e. status quo.) I feel the true figure would be somewhere around 99.8% and 99.98%, especially when a massive undercount from existing C/C++ projects is accounted for.
- humanrebar 3y ago
  He addresses this point in the article as well, discussing risks that that language community gets too fixated on one kind of safety while attackers shift to other concerns like supply chain, code injection, or leaked credentials.
  - lifthrasiir 3y ago
    Of course, but memory unsafety is one of the biggest enabler for security vulnerabilities. Attackers have shifted to other concerns when PHP became widespread enough for example, but PHP alone cannot be used to create a vulnerability common in C/C++ because of its memory safety (which is not even that good!), you need some other systems to combine multiple issues into a single coherent attack, and it's likely that C/C++'s memory unsafety has played a great role somewhere in between. He doesn't fully acknowledge this multiplicative aspect of memory (un)safety.
  - saghm 3y ago
    That sounds like a situation I'd describe as "a good problem to have". Almost completely eliminating a comment attack vector and having to figure out how to pivot to stamp out another type is far better than just not making any significant progress at all. If the concern were that they were already making progress on some of those other security concerns and they were worried that switching focus would risk gains they expect to make soon in those areas, I think that would be reasonable, but that doesn't seem to be the case. Is there any evidence that this concern is anything other than hypothetical? It comes across more as an attempt to justify not spending effort improving memory safety rather than something that anyone is actually concerned about.
saagarjha 3y ago
Absolutely not. Software that has 98% fewer memory safety issues is…still exploited. People just look harder and the costs go up a bit.
- TomSwirly 3y ago
  No, there is in fact a qualitative difference between a program where the expected number of CVEs is 1, and one where the expected number of CVEs is 0.02.
  - saagarjha 3y ago
    Yes, there are fewer CVEs. So?
    - oasisaimlessly 3y ago
      Are you being purposely dense? If the mean number of CVEs is low enough, some proportion of software has 0 exploitable flaws, and is invulnerable regardless of how much attackers spend.
      - saagarjha 3y ago
        I consider that most software that people use is sufficiently complex enough that it will not fall in this bucket.
saghm 3y ago
Is aiming for exact parity the best way to achieve that though? I'm skeptical that memory safe languages have 98% fewer CVES than C++ because their goal wass "have 2% of the CVEs that C++ has" and they succeeded and not "try to have no CVEs whatsoever" and they failed by a small amount.
pizlonator 3y ago
But how do you know that the language has eliminated 98% of vulnerabilities? 98% of what? CVEs? Something else?
pjdesno 3y ago
The most recent data I could find, from 2019, shows that 17% of CVEs are in PHP code, 12% in Java, and 11% in JavaScript - all memory-safe languages. Memory safety bugs are only one class of security vulnerabilities, and there's nothing magical about memory safeness that causes a developer using that language to suddenly become expert at writing secure code. For that matter, some vulnerabilities actually seem much more common in memory-safe languages - try searching the CVE database for "SQL injection c++" (287 results) vs javascript (3420), Java (2160), or PHP (11300).

humanrebar 3y ago

Or you can flip it around and ask why there isn't a body in the C and C++ community funding tangible advancements in the security and safety problem space the way the Python Foundation and Rust Foundation are.

nindalf 3y ago
I don't know about this. There are a lot of people being paid by their companies to work on the C++ committee and on various compiler teams. The author of the post we're discussing is a member of the committee and this article is an attempt to improve the security situation in C++. So funding isn't the issue. The issue is that the committee has a firm commitment to never introducing breaking changes. This commitment is so firm that it trumps literally any other interest, like making the language memory safe. That's why the author only suggests non-breaking changes in this article. Lots of people are going to have opinions on whether this approach is the right one for C++'s long term success, but I think we'll only know in 5-10 years.
- cesarb 3y ago
  > That's why the author only suggests non-breaking changes in this article. One of the proposals in the article is to change the meaning of things like "if (a != b > c)" and "if (0 <= index < max)". That changes program behavior and therefore is a breaking change (for instance, the code might accidentally be depending on the "wrong" results of these odd comparisons, and "fixing" them makes it go through an untested path which does the wrong thing).
  - jcelerier 3y ago
    It's ok if the current behaviour is changed into a compiler error
    - cesarb 3y ago
      I agree; while changing it into a compiler error could be considered "breaking" (it no longer compiles), it's not a silent break and forces the developer to fix the code. (I would only worry about developers doing the "obvious" fix to shut the compiler up without looking at the surrounding code to see if it was masking some other bug.)

adev_ 3y ago

> Take for example CVE-2022-21658 (https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html) in Rust, related to a filesystem API. It's true, this was a CVE in Rust and not a CVE in C++, but only because C++ doesn't regard the issue as a problem at all. That just plain wrong. Just simply wrong. And I hope it is not a lie done on purpose. The C++ community acknowledge the issue as soon as the Rust one posted the problem and issued a fix which is already deployed with major compilers [^1] [^2] It does not have a CVE associated since the issue was spotted within Rust stdlib first. This is this exact kind of FUD and zealotism that makes people hate the Rust community. I wish the community mature a bit on this aspect. [^1]: https://github.com/gcc-mirror/gcc/commit/ebf6175464768983a2d8c82c2d47771ee89192b8 https://github.com/gcc-mirror/gcc/commit/ebf6175464768983a2d... [^2]: https://github.com/llvm/llvm-project/commit/4f67a909902d8ab9e24e171201db189b661700bf https://github.com/llvm/llvm-project/commit/4f67a909902d8ab9...

nindalf 3y ago
> It does not have a CVE associated since the issue was spotted within Rust stdlib first. I don't see why this is true. Are you saying that people with affected code would have seen a Rust CVE and then updated their C++ toolchains? There seems to be no reason this shouldn't have been a C++ CVE other than the fact that C++ community has different standards for what constitutes safety. The lack of CVE associated with the fixes you pointed out support the original assertion rather than refuting it. In fact, I'll tell you why there was no CVE for C++ - concurrent access to filesystem APIs is undefined behaviour in C++ (https://en.cppreference.com/w/cpp/filesystem https://en.cppreference.com/w/cpp/filesystem). Reasonable people can disagree on this though, so I can see where you're coming from. There's no reason to immediately fling around accusations of lying and zealotry. It makes the writer look immature.
- adev_ 3y ago
  > There seems to be no reason this shouldn't have been a C++ CVE other than the fact that C++ community has different standards for what constitutes safety A security report has been filed for both compiler and actions taken for both of the major toolchain. This is a sign of mature security processes in used by both of the major C++ compiler implementations. CVE are one among many way to address security vulnerabilities, one way that is currently heavily under criticism [^1] > In fact, I'll tell you why there was no CVE for C++ - concurrent access to filesystem APIs is undefined behaviour in C++ The vulnerability reported (even in case of the Rust CVE) has nothing to do with a concurrent usage of the API. I think you do not really know what you are talking about here. > Reasonable people can disagree on this though, so I can see where you're coming from. There's no reason to immediately fling around accusations of lying and zealotry. It makes the writer look immature. My definition of immature includes the fact of throwing false statement over the internet, getting them refuted with sources and quote included. And still stance on them. This is a sign of immaturity. [^1]: https://portswigger.net/daily-swig/cvss-system-criticized-for-failure-to-address-real-world-impact https://portswigger.net/daily-swig/cvss-system-criticized-fo...

pornel 3y ago

The CVE/CVSS system lacks ability to deal with soundness issues. If the language or a library promises to catch a mistake, and it doesn’t, that’s not automatically exploitable unless the programmer has actually made that mistake. If there wasn’t a promise in the first place, there would be nothing to report. Unfortunately, CVE can’t see the difference between reporting a bug, or reporting a theoretical possibility of having a bug that never actually happened.

mattgreenrocks 3y ago
Frankly, I don't think industry is going to allow soundness issues to ever achieve parity of importance with what we think of as CVEs. There's simply too much code and mindshare around languages that don't worry as much about soundness. I'm not saying it is right, just that concerns around soundness will likely be hand-waved away. And it is to everyone's detriment.

deleted 3y ago

[deleted]

kllrnohj 3y ago

> It's true, this was a CVE in Rust and not a CVE in C++, but only because C++ doesn't regard the issue as a problem at all. The problem definitely exists in C++, but it's not acknowledged as a problem, let alone fixed. Can you find a link that substantiates your claim? You're throwing out some heavy accusations here that don't seem to match reality at all. Case in point, this was fixed in both major C++ libraries: https://github.com/gcc-mirror/gcc/commit/ebf6175464768983a2d8c82c2d47771ee89192b8 https://github.com/gcc-mirror/gcc/commit/ebf6175464768983a2d... https://github.com/llvm/llvm-project/commit/4f67a909902d8ab9e24e171201db189b661700bf https://github.com/llvm/llvm-project/commit/4f67a909902d8ab9... So what C++ community refused to regard this as an issue and refused to fix it? Where is your supporting evidence for your claims?

nindalf 3y ago
I stand corrected that the issue wasn't fixed (https://news.ycombinator.com/item?id=39680006 https://news.ycombinator.com/item?id=39680006). The issue was fixed, but no CVE by the C++ libraries. That reinforces the point that the author's attempt to equate 1 Rust CVE = 1 C++ CVE isn't valid.
kouteiheika 3y ago
> Can you find a link that substantiates your claim? You're throwing out some heavy accusations here that don't seem to match reality at all. Relevant piece of the standard: http://eel.is/c++draft/fs.race.behavior#1.sentence-2 http://eel.is/c++draft/fs.race.behavior#1.sentence-2 Officially it's undefined behavior. And here's a comment from the maintainer of the STL in MSVC regarding this: https://old.reddit.com/r/cpp/comments/151cnlc/a_safety_culture_and_c_we_need_to_talk_about/js8m9sp/ https://old.reddit.com/r/cpp/comments/151cnlc/a_safety_cultu...
- kllrnohj 3y ago
  That statement really doesn't support your claim and unsurprisingly Rust has the same basic caveat because of course it does, it's not possible for a language to guarantee exclusive IO access to the filesystem. https://doc.rust-lang.org/std/io/index.html#io-safety https://doc.rust-lang.org/std/io/index.html#io-safety

saghm 3y ago

Not to mention the weird conclusion that since no language has 0, that isn't the goal. I'm not sure I understand the logic that you shouldn't at least _try_ to not have any major security flaws. My interpretation of the CVE counts he mentions is that if your goal is zero, you might end up still having a few, but if your goal is just "few enough that people stop complaining about us being worse than other languages in a similar niche", you probably will end up not hitting that threshold either, which seems like a plausible explanation for how C++ is in this situation in the first place. The fact that he brings up C a bunch also seems like it could be related to this; it sort of feels like he's focusing too much on the idea of security as a competition between languages rather than something that's inherently worthwhile as a goal in its own right.

kllrnohj 3y ago
The point is that trying to hit 0 would be a huge breakage that would fragment the language, and there's no actual evidence to suggest such a thing is actually necessary. It's like your front door's lock. It doesn't have to be unpickable, unshimmable, absolutely secure. It just has to put up more of a fight than a brick through the window.
- jvanderbot 3y ago
  Yep yep. A better analogy might be that the door has to eliminate quick, quiet entry to the house since that would deter a huge majority of would-be burglars just due to the vastly increased danger of getting noticed. We have locks on windows, but rarely bars. We have alarms that trigger sirens, but rarely indoor locks. Eliminate quick and quiet, usually good enough.
- saghm 3y ago
  I think the problem with this analogy for me is that while you might not care to have your home be 100% impossible to break into, you _do_ want to aim for it to be broken into zero times a year. If my house got broken into 60 times a year for five years, and my neighbors got broken into 6 times a year for the same period, I still think my long-term goal would be to have my home _never_ broken into, even if it meant moving to a different neighborhood.

cozzyd 3y ago

What if you normalize for the amount of code in the wild? Relatively little software I use day to day have significant amounts of rust in them (only Firefox and my phone OS, probably...). Even in firefox, there is far more C++ than rust...

steveklabnik 3y ago
You’d also have to define what “use” means. Your traffic that goes through Cloudflare hits Rust code: does that count as a “use”? Sites you use that rely on AWS almost certainly hits Rust code, does that count as a “use”? I think it’s kind of stretching it, but these are services where issues in them could impact you, so I don’t think it’s a total non sequitur.
- cozzyd 3y ago
  that's totally fair, certainly there are web servers I use that are probably using rust somewhere, but I suspect it's still a relatively small amount of code (even if widely used!).
- fch42 3y ago
  This is true - and also misses one of the points Herb Sutter's article is making. I don't disagree at all with what seems the general sentiment here about the importance of memory safety. I also, though, don't disagree with Herb Sutter that there are other safety-relevant aspects in both programming and software deployment which aren't helped/prevented "merely" by using memsafe languages. Say, the "typical" rust laziness ... just unwrap() because well we know for sure it can't possibly be None, right ? Do that in a form of crit code path, and while that may not open you to an exploit, it'll still down your service and damn you to a crashloop. Yes, we should be using memsafe languages. Yes, we should be a little humble about bugs we may create. As important as it is to entirely eliminate one "critical" class, as important it is to realize even with that gone, bugs/issues/security problems will remain.
  - steveklabnik 3y ago
    > As important as it is to entirely eliminate one "critical" class, as important it is to realize even with that gone, bugs/issues/security problems will remain. Sure. Nobody believes that memory safety is the sole security issue. Or at least, no serious people, or any of the organizations doing advocacy around this issue.