3 ms·

Difference of course being that zero of these bugs will be due to buffer overflows or use after free or other memory bugs in safe rust, which is a huge source o

Difference of course being that zero of these bugs will be due to buffer overflows or use after free or other memory bugs in safe rust, which is a huge source of bugs in C[1]. I don't understand why this argument keeps coming up. Not all bugs are the same and when you make entire classes of bugs unrepresentable, that's a massive win, especially when they happen to be the class containing >60% of the highest severity bugs in C. https://www.chromium.org/Home/chromium-security/memory-safety/piechart.png https://www.chromium.org/Home/chromium-security/memory-safet...

lll-o-lll 4y ago
It’s not that simple. Rust is used in the system’s programming space and as a result it will be used in many places where unsafe ends up required to solve problems. There won’t be memory safety bugs in safe Rust, but there will be in the interop/unsafe layers. I think there is a strong argument to be made that if you need a lot of unsafe, Zig is going to be the safer language.
- hn92726819 4y ago
  > I think there is a strong argument to be made that if you need a lot of unsafe, Zig is going to be the safer language. I could see that. Haven't used zig but it does look very nice. > in many places where unsafe ends up required Yes, I definitely agree. I was specifically referring to the boundary of safe rust. I don't know how much more or less safe unsafe rust is vs c, but I do know that safe rust is certainly safer than c.
indymike 4y ago
> I don't understand why this argument keeps coming up. Not comment should be read as argument or part of a debate for or against using Rust or any other memory safe language. I made the comment because I've seen tool after tool come about to end the scourge of bugs in software... and so far my unconscious, untrained ability to find new and spectacular ways to create bugs has exceeded the ability of the makers of bug prevention tools to stop me.
kprotty 4y ago
> zero of these bugs will be due to buffer overflows or use after free or other memory bugs in safe rust buffer overflows [0] [1], use after frees [2] [3], and other memory bugs [4] [5] [6] can appear in safe rust from unsound unsafe internals. [0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-28875 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-2887... [1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000810 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000... [2] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31162 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3116... [3] https://github.com/rustsec/advisory-db/blob/main/crates/crossbeam/RUSTSEC-2018-0009.md https://github.com/rustsec/advisory-db/blob/main/crates/cros... [4] https://github.com/rustsec/advisory-db/blob/main/crates/tokio/RUSTSEC-2021-0124.md https://github.com/rustsec/advisory-db/blob/main/crates/toki... [5] https://github.com/rustsec/advisory-db/tree/main/crates/ https://github.com/rustsec/advisory-db/tree/main/crates/ [6] https://github.com/Qwaz/rust-cve https://github.com/Qwaz/rust-cve
- nindalf 4y ago
  Rust has a low bar for creating CVEs, because the standards for safety are higher. From the link you’re sharing > Fortunately, they are context-sensitive library APIs that are not usually used in a way that the bugs can be triggered. Many of them require very specific interaction to trigger (e.g., partially consume an iterator and zip() it with another iterator) that is not likely to appear in their daily usage. Here’s a concrete example that shows the difference between how different languages approach CVEs. Rust is not the only language affected by this TOCTOU bug (https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html) but other languages finesse it by saying “all bets are off when you’re interacting with the filesystem”. Therefore no CVE for them, while Rust ends up looking insecure in the eyes of those who count CVEs. What I’m saying is - don’t count CVEs without looking at the context and content of those CVEs. Don’t assume that some software is secure simply because they don’t file CVEs, because that’s an ostrich approach.
  - kprotty 4y ago
    > don’t count CVEs without looking at the context and content of those CVEs The CVEs are counted as they're memory issues (not only logical issues) that can technically surface in safe Rust code and are also considered UB in other languages (those which finesse other conditions to be "unspecified" instead of "undefined") too. CVEs have rating systems to better interpret their relevance. Whether these ratings incorporate how easy it is to trigger or how practical the damage could be is subjective. They primarily report potential exploits, not a standard for judgement. All this nuance though was lost with the parent commenter claiming "zero memory bugs in safe rust". > Don’t assume that some software is secure simply because they don’t file CVEs I agree. This extends across all languages. Another warning to add is that high profile security bugs can still occur without memory safety issues (with wormhole/dao exploits being practical examples).

lll-o-lll 4y ago

It’s not that simple. Rust is used in the system’s programming space and as a result it will be used in many places where unsafe ends up required to solve problems. There won’t be memory safety bugs in safe Rust, but there will be in the interop/unsafe layers. I think there is a strong argument to be made that if you need a lot of unsafe, Zig is going to be the safer language.

hn92726819 4y ago
> I think there is a strong argument to be made that if you need a lot of unsafe, Zig is going to be the safer language. I could see that. Haven't used zig but it does look very nice. > in many places where unsafe ends up required Yes, I definitely agree. I was specifically referring to the boundary of safe rust. I don't know how much more or less safe unsafe rust is vs c, but I do know that safe rust is certainly safer than c.

indymike 4y ago

> I don't understand why this argument keeps coming up. Not comment should be read as argument or part of a debate for or against using Rust or any other memory safe language. I made the comment because I've seen tool after tool come about to end the scourge of bugs in software... and so far my unconscious, untrained ability to find new and spectacular ways to create bugs has exceeded the ability of the makers of bug prevention tools to stop me.

kprotty 4y ago

> zero of these bugs will be due to buffer overflows or use after free or other memory bugs in safe rust buffer overflows [0] [1], use after frees [2] [3], and other memory bugs [4] [5] [6] can appear in safe rust from unsound unsafe internals. [0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-28875 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-2887... [1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000810 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000... [2] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31162 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3116... [3] https://github.com/rustsec/advisory-db/blob/main/crates/crossbeam/RUSTSEC-2018-0009.md https://github.com/rustsec/advisory-db/blob/main/crates/cros... [4] https://github.com/rustsec/advisory-db/blob/main/crates/tokio/RUSTSEC-2021-0124.md https://github.com/rustsec/advisory-db/blob/main/crates/toki... [5] https://github.com/rustsec/advisory-db/tree/main/crates/ https://github.com/rustsec/advisory-db/tree/main/crates/ [6] https://github.com/Qwaz/rust-cve https://github.com/Qwaz/rust-cve

nindalf 4y ago
Rust has a low bar for creating CVEs, because the standards for safety are higher. From the link you’re sharing > Fortunately, they are context-sensitive library APIs that are not usually used in a way that the bugs can be triggered. Many of them require very specific interaction to trigger (e.g., partially consume an iterator and zip() it with another iterator) that is not likely to appear in their daily usage. Here’s a concrete example that shows the difference between how different languages approach CVEs. Rust is not the only language affected by this TOCTOU bug (https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html) but other languages finesse it by saying “all bets are off when you’re interacting with the filesystem”. Therefore no CVE for them, while Rust ends up looking insecure in the eyes of those who count CVEs. What I’m saying is - don’t count CVEs without looking at the context and content of those CVEs. Don’t assume that some software is secure simply because they don’t file CVEs, because that’s an ostrich approach.
- kprotty 4y ago
  > don’t count CVEs without looking at the context and content of those CVEs The CVEs are counted as they're memory issues (not only logical issues) that can technically surface in safe Rust code and are also considered UB in other languages (those which finesse other conditions to be "unspecified" instead of "undefined") too. CVEs have rating systems to better interpret their relevance. Whether these ratings incorporate how easy it is to trigger or how practical the damage could be is subjective. They primarily report potential exploits, not a standard for judgement. All this nuance though was lost with the parent commenter claiming "zero memory bugs in safe rust". > Don’t assume that some software is secure simply because they don’t file CVEs I agree. This extends across all languages. Another warning to add is that high profile security bugs can still occur without memory safety issues (with wormhole/dao exploits being practical examples).