4 ms·

> which the "systems language" Rust necessarily runs on Strictly speaking, Rust does not need to run on a kernel. If anything, the Rust developers have explici

> which the "systems language" Rust necessarily runs on Strictly speaking, Rust does not need to run on a kernel. If anything, the Rust developers have explicitly steered the language to be suitable for bare-metal situations. > So the Linux or BSD kernels... have not gotten it right ...Because they haven't? Just look at the CVE databases. A cursory search gives: * https://www.cvedetails.com/cve/CVE-2018-6916/ https://www.cvedetails.com/cve/CVE-2018-6916/ - FreeBSD: Improper validation and a use-after-free * https://www.cvedetails.com/cve/CVE-2019-5606/ https://www.cvedetails.com/cve/CVE-2019-5606/ - FreeBSD: Incorrect signal handling leading to write after free * https://www.cvedetails.com/cve/CVE-2019-15919/ https://www.cvedetails.com/cve/CVE-2019-15919/ - Linux: Use-after-free * https://www.cvedetails.com/cve/CVE-2019-15292/ https://www.cvedetails.com/cve/CVE-2019-15292/ - Linux: Use-after-free * https://www.cvedetails.com/cve/CVE-2019-15504/ https://www.cvedetails.com/cve/CVE-2019-15504/ - Linux: Double free In addition, Microsoft has said that ~70% of their CVEs are memory safety issues [0], and have been for many years. So no, easily accessible memory safety in C is not a solved issue yet. There are various techniques and tools that can be used to reduce or eliminate memory errors, but they have not seen widespread adoption for one reason or another. [0]: https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-more-secure-code/ https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro...

cpk10 7y 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 7y 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 7y 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 7y 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 7y 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 7y 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.

cpk10 7y 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 7y 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 7y 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 7y 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 7y 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 7y 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.