Herb Sutter on increasing safety in C++

Posted Mar 14, 2024 9:55 UTC (Thu) by ianmcc (subscriber, #88379)
In reply to: Herb Sutter on increasing safety in C++ by itsmycpu
Parent article: Herb Sutter on increasing safety in C++

And it looks like all of the C/C++ CVE's from 2024 are actually C programs. Mostly from the linux kernel actually, so it is quite unfair to pin all of these on C++. Indeed, the most recent mention of C++ in the CVE list is July 2023, and that is a C program, not C++ ("PJSIP is a free and open source multimedia communication library written in C with high level API in C, C++, Java, C#, and Python languages"). The next one in the list, CVE-2023-28831, is an integer overflow that could be C or C++. In fact I can't see *any* CVE's in the last year that can definitely be attributed to C++ based on the brief descriptions.

Herb Sutter on increasing safety in C++

Posted Mar 14, 2024 13:28 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (4 responses)

Sure, so if prevalence is what matters apparently nobody is writing C++ right? We don't need to worry about how difficult it might be to replace C++ as apparently none of the C++ projects are using C++ anyway. Phew.

I think the fact you were able to look at the C++ vulnerabilities reported in most of 2023 and decide they can't "definitely be attributed to C++" reminds us that the only value CVEs were definitively intended to deliver was to allow us to agree about which vulnerability we're talking about. We don't know what the bug really is, which language the code was written in, or really anything but we've got an ID for it so that's something.

Herb Sutter on increasing safety in C++

Posted Mar 14, 2024 16:23 UTC (Thu) by ianmcc (subscriber, #88379) [Link] (3 responses)

Not sure what you mean here, the CVE list obviously isn't filtering specifically on C++ (otherwise none of the Linux kernel CVE's would be there, for a start!).

Herb Sutter on increasing safety in C++

Posted Mar 15, 2024 0:11 UTC (Fri) by tialaramex (subscriber, #21167) [Link] (2 responses)

Herb is (if I'm generous) completely incompetent and doesn't understand how URLs work, I guess I was mistaken in assuming LWN readers would know that's not how URLs work. Herb wrote this URL which searches for the letter C (with two spaces, that's what the plus symbols do, I expect the spaces are just trimmed in searching but even if not they're irrelevant):

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=c++

The URL you'd obviously actually write to search for the text C++ is:

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=c%2B%2B

I further assumed you were talking about the actual C++ CVEs reported in the last year, rather than that you'd taken Herb's word for it and assumed whatever nonsense he found by searching for the letter C is the C++ vulnerabilities. It's definitely possible (if you're a C++ proponent) to insist that all the bugs in C++ just aren't really C++, just as a "True" Scotsman would never use sugar on porridge.

But yeah, sure, if you follow Herb's link you're mostly looking at the spew of Linux kernel CVEs and you learn nothing.

Herb Sutter on increasing safety in C++

Posted Mar 15, 2024 1:48 UTC (Fri) by tialaramex (subscriber, #21167) [Link]

In the r/cpp Reddit, I found this very nice link https://github.com/advisories?page=1&query=cwe%3A787+...

This is asking GitHub to match CWE-787 (bounds miss write) against 2024 CVEs. Obviously not all of these will be C++ either, but it should be much less noisy than Herb's "Every CVE with the letter C in it" link, and of course "bounds misses" are exactly one of the things the Memory Safe Languages defend against.

Herb Sutter on increasing safety in C++

Posted Mar 15, 2024 14:31 UTC (Fri) by ianmcc (subscriber, #88379) [Link]

Thanks for the correction! I am not so familiar with RFC 3986, indeed, the '+' character is reserved for this purpose.

Herb Sutter on increasing safety in C++

Posted Mar 14, 2024 19:49 UTC (Thu) by roc (subscriber, #30627) [Link] (1 responses)

Chrome is C++ and has 20 CVEs in 2024 according to https://www.cvedetails.com/product/15031/Google-Chrome.ht.... So I don't know what the MITRE list is counting.

Herb Sutter on increasing safety in C++

Posted Mar 14, 2024 19:53 UTC (Thu) by roc (subscriber, #30627) [Link]

I guess someone has to attach keywords manually to CVEs? So these MITRE queries are extremely sensitive to whether whoever files the CVE attaches the "c++" or "rust" keywords. Which makes them somewhat more meaningless than they already were.

Herb Sutter on increasing safety in C++

Posted Mar 14, 2024 20:01 UTC (Thu) by draco (subscriber, #1792) [Link]

Yeah, I was poking at the queries Herb used (I thought it really suspect he focused only on 2024 when this year has just begun) and the data is just nonsense as far as I could tell.

One year, there were more "rust" CVEs than "C++" ones by 2:1, and I just don't find that remotely credible. Mind you, my processing of the data was extremely sloppy (counting every hit of a token that matched the CVE ID pattern in each HTML page, removing duplicates and collating by year).

But implementation language isn't a field in the CVE records, so I think this is all just noise. Getting usable data for this question would require a fair amount of research, and even then, commercial software doesn't tend to talk about implementation language, so you're going to have gaps/skews in the data.

Anyway, I doubt that's what ultimately swayed him to concede that C/C++ has a problem. I think he was really using this data to say that C++ doesn't need to eliminate 100% of memory safety issues to be "good enough," which is an interesting statement since I don't think anyone informed is even claiming that.

The whole response is an interesting mix of "giving context" and concession.