undefined

points

[-]

This is a dumb argument imo. Critical vulnerabilities are mostly due to memory bugs (and not for a lack of other kinds of bugs). Most people relying on programs written in C (or even C++) should consider plans for migrating to software created with toolchains from this century. You cannot indefinitely carry on this tech debt.

by veltas5 hours ago|

parent|

[-]

Here are some CVEs identified in Rust coreutils [1]. These are mostly really trivial issues. I'd bet money that the nastier logic bugs are still in there and that the people who maintained the old C utils or helped identify the old bugs can find similar ones in these utils, although half these issues probably never appeared in the C version because Rust is much more complicated than C so makes it easier to hide logic bugs in plain site, looking at many of the issues in this article they seem like bugs that are extremely unlikely to get written in C, like accidentally forcing everything to be UTF-8, or aborting on routine errors.

[1] https://corrode.dev/blog/bugs-rust-wont-catch/

by TZubiri8 hours ago|

parent|

prev|

[-]

One issue with this argument is that, almost everything is memory, especially in C. It's not really descriptive. If you write a reactionary language like Rust, it may be possible that you just fix one type of issue (with an error type taxonomy that's not very refined), and end up with a language that does not necessarily cause less bugs and vulns, but that causes less vulns that can be classified as that type of issue, while increasing other types of bugs/vulns, either of an existing type, or of a new type that only exists in that new language.

Like are we empirically seeing less Rust CVEs? Adjusted for popularity of software and perhaps age of software.

by 3OCSzk5 hours ago|

parent|

[-]

Are you saying by attempting to reduce certain types of bug category such as memory safety, other types of vulns would suddenly be increased because of it? It sounds to me like you are saying we shouldn't treat common cold because cancer rates might increase. And what do you mean by reactionary?

by Gigachad9 hours ago|

parent|

prev|

[-]

It’s also never been easier to replace C programs with safe alternatives.

by Aachen9 hours ago|

prev|

[-]

Yes, you'd introduce a lot of new bugs because the code is newly written[1], but eventually you'll get to the same maturity as today except you can't have all these devastating memory-handling-related vulnerabilities

The question is whether your software will be in use long enough to be worth the cost of change more than whether it's a good idea in the long run. For Linux, I'd argue that that's likely. At least new code would ideally be contributed in a safe language, where practically possible (there'll surely be places where you need to deal with memory as a kernel)

Relevant article: reducing memory vulnerabilities through a combination of memory-safe languages and an exponential decrease of bugs as existing code ages https://security.googleblog.com/2024/09/eliminating-memory-s..., from which I'll also quote my reference for [1]: "A large-scale study of vulnerability lifetimes published in 2022 in Usenix Security [...] found that the vast majority of vulnerabilities reside in new or recently modified code"

by winwang8 hours ago|

prev|

[-]

I'm not suggesting anything like "rewrite in Rust", at least not in general. I'm simply poking at the fact that use-after-free (and other such issues) are effectively deprecated classes of bugs.