3 ms·

It is true that a lot of people like to file CVEs for extremely theoretical security issues. See for example - https://nvd.nist.gov/vuln/detail/CVE-2023-0687 h

It is true that a lot of people like to file CVEs for extremely theoretical security issues. See for example - https://nvd.nist.gov/vuln/detail/CVE-2023-0687 https://nvd.nist.gov/vuln/detail/CVE-2023-0687 The CVE is correct that the “gmon” component of the GNU C Library contains memory corruption bugs. In fact, I’ve found even more than the specific one that CVE is about. But, the claim that this is a security vulnerability is a bit silly. These are profiler functions, which are usually only called in non-production builds with profiling enabled (gcc -pg), and even then only from CRT startup code. It is rather unlikely an attacker can exploit any of these bugs in them without already having the ability to run arbitrary code in the process, at which point they don’t need these functions, they’ve already got all these bugs have to give them.

steveklabnik 4y ago
Yeah, this kind of thing is tricky. Rust has had some CVEs filed against the standard library that are CVEs because of Rust's guarantees. Same issues existed in the C++ standard library but since it's UB, not a CVE there.
- saagarjha 4y ago
  Do the C++ libraries require changes as a result of these issues?
  - steveklabnik 4y ago
    Nope, their docs just say "don't do that" and so you're expected not to do that.
    - saagarjha 4y ago
      Ok, so this isn't an issue, right?
      - steveklabnik 4y ago
        I'm not sure what you mean by "isn't an issue." All I'm saying is that the CVE process is a human one, with lots of nuance. You're pointing out one aspect of that, that some CVEs are very practical, and others are more theoretical. I was trying to chime in with a similar way in which this is expressed, in that an identical bug in the standard library of one language may be a CVE, while in the other, it may not be a CVE, even with the same problem in both of them. That's "not an issue" in the sense that yeah, of course, Rust cares about this a lot more, so it's a more serious problem in Rust, so this process is legitimate, but it is in the sense that depending on how you're trying to do comparisons, there's more complexity than simply tallying up CVE counts.
        saagarjha 4y ago
        CVEs aren’t really anything but an identifier for a problem. It says nothing about its severity, exploitability, or in some cases, whether it is even an actual bug. You can effectively get one for ~free. This is one of the reasons why tallying up their counts is not useful, but others include things like “people focus on some software more”. With that said, I wouldn’t bring up this distinction here. The problem here is identical but Rust bills itself as a language where it takes responsibility for correctness bugs while C++ is a language where correctness is something that the programmer is supposed to provide. That doesn’t mean the Rust CVE is any less valid or complicated than the other CVE, it’s just that the bug would get assigned to Chromium or IOAccelerator. So if you’re saying that you shouldn’t just look at the number of CVEs and claim that Rust is somehow less secure: yes, absolutely. But if you’re saying this because you want to point out that Rust CVEs are somehow lesser because they are self-imposed, then no, that’s not true.
        steveklabnik 4y ago
        > if you’re saying that you shouldn’t just look at the number of CVEs and claim that Rust is somehow less secure Even more general than that, it’s not about Rust specifically, just that number of CVEs alone, with no other context, is a bad metric. > That Rust CVEs are somehow lesser because they are self-imposed I am not saying that, yes. That would be incorrect.

steveklabnik 4y ago

Yeah, this kind of thing is tricky. Rust has had some CVEs filed against the standard library that are CVEs because of Rust's guarantees. Same issues existed in the C++ standard library but since it's UB, not a CVE there.

saagarjha 4y ago
Do the C++ libraries require changes as a result of these issues?
- steveklabnik 4y ago
  Nope, their docs just say "don't do that" and so you're expected not to do that.
  - saagarjha 4y ago
    Ok, so this isn't an issue, right?
    - steveklabnik 4y ago
      I'm not sure what you mean by "isn't an issue." All I'm saying is that the CVE process is a human one, with lots of nuance. You're pointing out one aspect of that, that some CVEs are very practical, and others are more theoretical. I was trying to chime in with a similar way in which this is expressed, in that an identical bug in the standard library of one language may be a CVE, while in the other, it may not be a CVE, even with the same problem in both of them. That's "not an issue" in the sense that yeah, of course, Rust cares about this a lot more, so it's a more serious problem in Rust, so this process is legitimate, but it is in the sense that depending on how you're trying to do comparisons, there's more complexity than simply tallying up CVE counts.
      - saagarjha 4y ago
        CVEs aren’t really anything but an identifier for a problem. It says nothing about its severity, exploitability, or in some cases, whether it is even an actual bug. You can effectively get one for ~free. This is one of the reasons why tallying up their counts is not useful, but others include things like “people focus on some software more”. With that said, I wouldn’t bring up this distinction here. The problem here is identical but Rust bills itself as a language where it takes responsibility for correctness bugs while C++ is a language where correctness is something that the programmer is supposed to provide. That doesn’t mean the Rust CVE is any less valid or complicated than the other CVE, it’s just that the bug would get assigned to Chromium or IOAccelerator. So if you’re saying that you shouldn’t just look at the number of CVEs and claim that Rust is somehow less secure: yes, absolutely. But if you’re saying this because you want to point out that Rust CVEs are somehow lesser because they are self-imposed, then no, that’s not true.
        steveklabnik 4y ago
        > if you’re saying that you shouldn’t just look at the number of CVEs and claim that Rust is somehow less secure Even more general than that, it’s not about Rust specifically, just that number of CVEs alone, with no other context, is a bad metric. > That Rust CVEs are somehow lesser because they are self-imposed I am not saying that, yes. That would be incorrect.