Hacker News Reader

Comment by criddell | Hacker News Reader

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

View on HN

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.

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).

Except the CVEs in Rust are far more likely to be low severity issues that C++ would never acknowledge to begin with.

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.

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.

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.

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.

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.

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.

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.

That seems far fetched to me. The vast majority of zero-days are still memory safety issues, and it would be an absolute miracle if the C++ community can get that ship turned around in under 20 years. Even 50 seems unreasonable honestly.

But how do you know that the language has eliminated 98% of vulnerabilities?

98% of what? CVEs? Something else?

Absolutely not. Software that has 98% fewer memory safety issues is…still exploited. People just look harder and the costs go up a bit.

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.

Yes, there are fewer CVEs. So?

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.

I consider that most software that people use is sufficiently complex enough that it will not fall in this bucket.

Reply on news.ycombinator.com