4 ms·

That 70% CVE figure is misleading: C and C++ obviously have a far higher market share, especially in fundamental Internet applications and kernels. So they have

by cpk10 6y ago

That 70% CVE figure is misleading: C and C++ obviously have a far higher market share, especially in fundamental Internet applications and kernels. So they have a higher number of CVE reports. But let's examine Rust despite its low market share: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12083 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1208... https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1010299 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1010... https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000810 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000...

GolDDranks 6y ago
Note that none of these CVEs is exploitable without the developer _also_ misusing the API or exposing the vulnerability to some data that the attacker can control. It's unclear whether these can be thought of as bona fide security holes.
bsder 6y ago
You might not want to throw that stone from the glass house that is the C standard library or the C++ standard library. Both of those have had vicious holes (memcpy/memmove anyone? s/f/printf? I can go on and on ...) that STILL aren't fixed (at least most implementation now just pass memcpy to memmove and be done with it). And part of the reason why musl and glibc are incompatible is that they disagree on certain things that produce vulnerabilities.
- jfkebwjsbx 6y ago
  What are you even talking about? There is nothing to fix in the functions you mentioned, and no sane implementation calls memmove() from memcpy(). I hope you realize those functions are some of the most fundamental in the ISO C standard, defined by dozens of major companies. I am pretty sure their engineers know what they are doing...?
  - bsder 6y ago
    > There is nothing to fix in the functions you mentioned, and no sane implementation calls memmove() from memcpy(). Thanks. Now I know not to argue with you any more.
aw1621107 6y ago
If the 70% CVE figure can be interpreted as misleading then that was a failure of wording on my part. The intent behind the short list of CVEs was to refute GP's claim that high-profile open-source kernels no longer suffer from memory safety/management issues, and the 70% CVE figure was just to show that high-profile closed-source software isn't much better. I think that the 70% figure is an appropriate example in that case. Now if you wanted to examine whether Rust programs suffer from fewer memory-related issues, you need to look at more than a few CVEs here and there for both Rust and C/C++ programs. As you pointed out, C/C++ programs are much more prevalent, so looking at the absolute number of CVEs isn't a good comparison. Ideally, one would need to find a Rust and C/C++ implementations of programs with very similar feature sets and look at the various vulnerabilities, such as by looking at fuzzer trophy cases for similar programs and compare how many of the uncovered errors are memory-related.

by cpk10 6y ago

GolDDranks 6y ago

Note that none of these CVEs is exploitable without the developer _also_ misusing the API or exposing the vulnerability to some data that the attacker can control. It's unclear whether these can be thought of as bona fide security holes.

bsder 6y ago

You might not want to throw that stone from the glass house that is the C standard library or the C++ standard library. Both of those have had vicious holes (memcpy/memmove anyone? s/f/printf? I can go on and on ...) that STILL aren't fixed (at least most implementation now just pass memcpy to memmove and be done with it). And part of the reason why musl and glibc are incompatible is that they disagree on certain things that produce vulnerabilities.

jfkebwjsbx 6y ago
What are you even talking about? There is nothing to fix in the functions you mentioned, and no sane implementation calls memmove() from memcpy(). I hope you realize those functions are some of the most fundamental in the ISO C standard, defined by dozens of major companies. I am pretty sure their engineers know what they are doing...?
- bsder 6y ago
  > There is nothing to fix in the functions you mentioned, and no sane implementation calls memmove() from memcpy(). Thanks. Now I know not to argue with you any more.

aw1621107 6y ago

If the 70% CVE figure can be interpreted as misleading then that was a failure of wording on my part. The intent behind the short list of CVEs was to refute GP's claim that high-profile open-source kernels no longer suffer from memory safety/management issues, and the 70% CVE figure was just to show that high-profile closed-source software isn't much better. I think that the 70% figure is an appropriate example in that case. Now if you wanted to examine whether Rust programs suffer from fewer memory-related issues, you need to look at more than a few CVEs here and there for both Rust and C/C++ programs. As you pointed out, C/C++ programs are much more prevalent, so looking at the absolute number of CVEs isn't a good comparison. Ideally, one would need to find a Rust and C/C++ implementations of programs with very similar feature sets and look at the various vulnerabilities, such as by looking at fuzzer trophy cases for similar programs and compare how many of the uncovered errors are memory-related.