4 ms·

I am not a Rust or C++ fanboy, and I am happy that we are moving towards a future where there are less memory bugs, but… are we really? - https://www.infoq.com

by mk89 4y ago

I am not a Rust or C++ fanboy, and I am happy that we are moving towards a future where there are less memory bugs, but… are we really? - https://www.infoq.com/news/2021/11/rudra-rust-safety/ https://www.infoq.com/news/2021/11/rudra-rust-safety/ - https://cve.report/vendor/rust-lang https://cve.report/vendor/rust-lang And you can find online similar links and research on the topic. All it takes is that you use that specific piece of code at the wrong time, and that’s it: your system which you once believed to be safe is not anymore safe. And you know what? You don’t even know what a sanitizer is, because they told you that Rust is a memory safe language and you don’t need anything else than the rust compiler - this is how I find 99% of today’s articles about Rust. Sure, today being Rust less used than C/C++ will clearly show less CVEs. The question is … once it’s in the wild (and by this I mean “major” libs or serious shit done in Rust) how can you prevent such bugs without a runtime sanitizer? Beware that such CVEs can affect Rust Standard library as well, not just an unknown library. Again, there is no way of escaping bad programming and bad practices, no matter which language you use. Someone might argue that in Python or Java you can still do bad stuff, however, the likelihood is way lower, especially because most of your Java libraries will very likely be written in Java - unless you know it’s using JNI under the hood etc.

joshuamorton 4y ago
Yes. They found 250 bugs after analyzing the entirety of rust and all of it's packages. There are probably more memory safety bugs in the python standard library and top 50k packages.
- masklinn 4y ago
  The rust project itself also has an extremely aggressive CVE policy (which many find too aggressive): if unsoundness is found in an API it gets a CVE, no matter how convoluted, and how unlikely it is to get into that situation, with absolutely no guarantee of any code in the wild coming even close to the unsoundness. Essentially, the Rust standard is that more or less every line of the C++ standard is a CVE. Hell, the Rust project releases CVE for things other languages literally just shrug about e.g. https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html The C++ people just go "lol nothing in std::filesystem is safe we don't give a shit". The spec pretty much says it's UB to have other programs interact with the filesystem: http://eel.is/c++draft/fs.race.behavior#1.sentence-2 http://eel.is/c++draft/fs.race.behavior#1.sentence-2
  - steveklabnik 4y ago
    Many CVEs in the Rust ecosystem aren’t filed by the Rust project itself. Anyone can file a CVE, it does not require involvement of upstream. That said things that happen in the language or standard libraries like the one you linked, are often (but not always!) filed by the project.
  - deleted 4y ago
    [deleted]
howinteresting 4y ago
Every single time you (or anyone else) points to the number of CVEs as a metric, you're contributing to the computing world being less safe because you're incentivizing people to file fewer CVEs. https://en.wikipedia.org/wiki/Goodhart's_law https://en.wikipedia.org/wiki/Goodhart's_law
IshKebab 4y ago
Did you read this bit? > It could appear that these results undermine the belief that Rust safety model represents an improvement over other languages, e.g. C++, but this would not be correct, say the researchers behind Rudra, who still consider Rust safety a supreme improvement. They found ~100 security issues in 45k packages. That's clearly better than C++.
- mk89 4y ago
  I didn’t say it’s not an improvement. I just wonder who will you blame once you have a hacker exploiting that exact CVE which you didn’t know about because they sold you rust as memory safe language, so you didn’t take the time to run any sanitizer or similar. Does Rust provide a way to check if you’re using unsafe code? What if I want to disable that? If I need to make a mission critical software I need to be aware of what I am deploying. If on the other hand we want Rust to be the new JS for backend, then yes so be it, we improved over c++, well done.
  - bluGill 4y ago
    Rust would have prevented about half of the CVEs in C code (I've seen a few different studies with somewhat different results, half is close enough for discussion). The other half is on you to write good code. Note that the half Rust would prevent tends to be less impactful, still a CVE, but the exploit is less impactful to end users.
    - mk89 4y ago
      If we leave it to the programmer, what are we improving? We did a big improvement, but why can’t we disable “unsafe”? That would leave absolutely no margin for such errors.
      - masklinn 4y ago
        > We did a big improvement, but why can’t we disable “unsafe”? Because there are things which literally can not be safe, and rust will not let you get away with pretending.
fiedzia 4y ago
> they told you that Rust is a memory safe language and you don’t need anything else than the rust compiler - this is how I find 99% of today’s articles about Rust. It is - as long as you don't use unsafe. Which is very rare, so we've made huge progress here already. Validation for cases where unsafe is necessary is needed and welcomed, but doesn't change the fact that 99% safe Rust is much better than 100% unsafe C/C++. > Again, there is no way of escaping bad programming and bad practices, no matter which language you use. Escape entirely maybe not. Eliminate most of it - definitely.
- mk89 4y ago
  > It is - as long as you don't use unsafe. That's what I tried to show in the previous post: it's just not true, because if you rely even on an unsafe function from the standard library affected by a CVE, you're just fucked as if it was in C, C++ or other languages. The only difference is that you don't know what's happening under the hood and you feel "safe" because that's how they sold the language to you. Until you get hacked and "hey we didn't know...". You just use that "unsafe zip/unzip" function you find in the docs, and with maybe with the wrong input (a weird filename or so) it happens to create undefined behavior that opens up the door to vulnerabilities. I really believe that Rust, Swift and lots of new[er] programming languages improve in terms of memory safety (at least on the high level), however, we need to admit that they are being sold for what they are not -> memory safe. When I read memory safe it means that it cannot happen at all, and therefore I don't have to think about that kind of stuff when I write a program. It'd be more honest to say: it's memory safe until: - you use unsafe - the libs you rely on use unsafe (and go figure once you start to pull a lib that pulls another lib etc.) - the standard library functions you use use unsafe It's an important remark, because the next generations of programmers will build programs based on a false assumption - that they don't have to worry about certain types of errors, while it's just not true. EDIT: maybe it's just my definition of memory safe too "strict", not sure. Memory safe to me means -> it just can't happen. That's it.
  - fiedzia 4y ago
    > When I read memory safe it means that it cannot happen at all, and therefore I don't have to think about that kind of stuff when I write a program. I've never needed to use unsafe in my Rust applications, which means that my code is 100% memory safe (by Rust definition of course). I expect libraries I am using to provide safe abstractions over unsafe, if there is any there. Sure, there were bugs (including Rust stdlib), but such small scale effectively means that this problems disappeared comparing to languages that aren't safe and that means all I need to do is maybe update some dependency once a year. It's that rare, so I will call it safe and solved problem. We can move to next one (and there are many). > It'd be more honest to say: it's memory safe until: Which is what most Rust introductions I've seen will say. I don't think anyone misunderstood this part.

by mk89 4y ago

joshuamorton 4y ago

Yes. They found 250 bugs after analyzing the entirety of rust and all of it's packages. There are probably more memory safety bugs in the python standard library and top 50k packages.

masklinn 4y ago
The rust project itself also has an extremely aggressive CVE policy (which many find too aggressive): if unsoundness is found in an API it gets a CVE, no matter how convoluted, and how unlikely it is to get into that situation, with absolutely no guarantee of any code in the wild coming even close to the unsoundness. Essentially, the Rust standard is that more or less every line of the C++ standard is a CVE. Hell, the Rust project releases CVE for things other languages literally just shrug about e.g. https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html The C++ people just go "lol nothing in std::filesystem is safe we don't give a shit". The spec pretty much says it's UB to have other programs interact with the filesystem: http://eel.is/c++draft/fs.race.behavior#1.sentence-2 http://eel.is/c++draft/fs.race.behavior#1.sentence-2
- steveklabnik 4y ago
  Many CVEs in the Rust ecosystem aren’t filed by the Rust project itself. Anyone can file a CVE, it does not require involvement of upstream. That said things that happen in the language or standard libraries like the one you linked, are often (but not always!) filed by the project.
- deleted 4y ago
  [deleted]

howinteresting 4y ago

Every single time you (or anyone else) points to the number of CVEs as a metric, you're contributing to the computing world being less safe because you're incentivizing people to file fewer CVEs. https://en.wikipedia.org/wiki/Goodhart's_law https://en.wikipedia.org/wiki/Goodhart's_law

IshKebab 4y ago

Did you read this bit? > It could appear that these results undermine the belief that Rust safety model represents an improvement over other languages, e.g. C++, but this would not be correct, say the researchers behind Rudra, who still consider Rust safety a supreme improvement. They found ~100 security issues in 45k packages. That's clearly better than C++.

mk89 4y ago
I didn’t say it’s not an improvement. I just wonder who will you blame once you have a hacker exploiting that exact CVE which you didn’t know about because they sold you rust as memory safe language, so you didn’t take the time to run any sanitizer or similar. Does Rust provide a way to check if you’re using unsafe code? What if I want to disable that? If I need to make a mission critical software I need to be aware of what I am deploying. If on the other hand we want Rust to be the new JS for backend, then yes so be it, we improved over c++, well done.
- bluGill 4y ago
  Rust would have prevented about half of the CVEs in C code (I've seen a few different studies with somewhat different results, half is close enough for discussion). The other half is on you to write good code. Note that the half Rust would prevent tends to be less impactful, still a CVE, but the exploit is less impactful to end users.
  - mk89 4y ago
    If we leave it to the programmer, what are we improving? We did a big improvement, but why can’t we disable “unsafe”? That would leave absolutely no margin for such errors.
    - masklinn 4y ago
      > We did a big improvement, but why can’t we disable “unsafe”? Because there are things which literally can not be safe, and rust will not let you get away with pretending.

fiedzia 4y ago

> they told you that Rust is a memory safe language and you don’t need anything else than the rust compiler - this is how I find 99% of today’s articles about Rust. It is - as long as you don't use unsafe. Which is very rare, so we've made huge progress here already. Validation for cases where unsafe is necessary is needed and welcomed, but doesn't change the fact that 99% safe Rust is much better than 100% unsafe C/C++. > Again, there is no way of escaping bad programming and bad practices, no matter which language you use. Escape entirely maybe not. Eliminate most of it - definitely.

mk89 4y ago
> It is - as long as you don't use unsafe. That's what I tried to show in the previous post: it's just not true, because if you rely even on an unsafe function from the standard library affected by a CVE, you're just fucked as if it was in C, C++ or other languages. The only difference is that you don't know what's happening under the hood and you feel "safe" because that's how they sold the language to you. Until you get hacked and "hey we didn't know...". You just use that "unsafe zip/unzip" function you find in the docs, and with maybe with the wrong input (a weird filename or so) it happens to create undefined behavior that opens up the door to vulnerabilities. I really believe that Rust, Swift and lots of new[er] programming languages improve in terms of memory safety (at least on the high level), however, we need to admit that they are being sold for what they are not -> memory safe. When I read memory safe it means that it cannot happen at all, and therefore I don't have to think about that kind of stuff when I write a program. It'd be more honest to say: it's memory safe until: - you use unsafe - the libs you rely on use unsafe (and go figure once you start to pull a lib that pulls another lib etc.) - the standard library functions you use use unsafe It's an important remark, because the next generations of programmers will build programs based on a false assumption - that they don't have to worry about certain types of errors, while it's just not true. EDIT: maybe it's just my definition of memory safe too "strict", not sure. Memory safe to me means -> it just can't happen. That's it.
- fiedzia 4y ago
  > When I read memory safe it means that it cannot happen at all, and therefore I don't have to think about that kind of stuff when I write a program. I've never needed to use unsafe in my Rust applications, which means that my code is 100% memory safe (by Rust definition of course). I expect libraries I am using to provide safe abstractions over unsafe, if there is any there. Sure, there were bugs (including Rust stdlib), but such small scale effectively means that this problems disappeared comparing to languages that aren't safe and that means all I need to do is maybe update some dependency once a year. It's that rare, so I will call it safe and solved problem. We can move to next one (and there are many). > It'd be more honest to say: it's memory safe until: Which is what most Rust introductions I've seen will say. I don't think anyone misunderstood this part.