5 ms·

Yes... but before you start feeling too sure about Rust protecting you from creating bugs, also consider this more cautionary (and very entertaining) tale poste

by rob74 4y ago

Yes... but before you start feeling too sure about Rust protecting you from creating bugs, also consider this more cautionary (and very entertaining) tale posted on HN today: https://hacks.mozilla.org/2022/06/fuzzing-rust-minidump-for-embarrassment-and-crashes/ https://hacks.mozilla.org/2022/06/fuzzing-rust-minidump-for-...

rq1 4y ago
Well you’d have these bugs, plus the memory bugs in other languages.
- fnord123 4y ago
  They already did. Hence the rewrite from C++ to Rust.
proto_lambda 4y ago
You mean the tale of someone rewriting a very complex and fiddly software from scratch, having it work great in production, and then using the ecosystem's great tooling to easily find and eliminate even more bugs than what the language already protected them from?
- kjksf 4y ago
  The thing they rewrote also worked great in production. And fuzzing originated in C / C++ tools and is available for them as well, probably more diverse and mature than what is available in Rust. The point you did ignore was: Rust is being sold as magically making software safe and people selling that completely ignore the fact that logical bugs are also a thing. Which Rust evangelists find difficult to acknowledge because security is that one thing that Rust has going for it. So difficult that you would rather try to misdirect than to acknowledge that software written in Rust will crash. And when processing arbitrary user output, it'll crash badly when not written with care and fuzzed a lot. Kind of like C++.
  - proto_lambda 4y ago
    > The thing they rewrote also worked great in production. It didn't for them, that's why they rewrote it. > Rust is being sold as magically making software safe and people selling that completely ignore the fact that logical bugs are also a thing. By whom? I don't think memory safety bugs are the only class of bugs, and neither do you, so who are you arguing against? > Which Rust evangelists find difficult to acknowledge because security is that one thing that Rust has going for it. Hard disagree. Rust also offers a solid type system, pain-free dependency management and all-around good tooling, just to name a few. It's much more than a "memory-safe C++" or whatever. > And when processing arbitrary user output, it'll crash badly If your definition of "badly" is "at a well-defined point, without any memory corruption", sure. But even here memory safety prevents what could be a much more painful debugging experience.
  - rob74 4y ago
    What you said, although I would have probably phrased it less harshly :) But yes, my point was that there are a lot of enthusiastic articles about how Rust can prevent "whole classes of bugs", which mostly gloss over the fact that there are other classes of bugs that it doesn't prevent. Of course this doesn't mislead experienced developers, but I'm not so sure about novices or less technically inclined people.
    - tremon 4y ago
      which mostly gloss over the fact that there are other classes of bugs that it doesn't prevent That's nothing more than a technically-dressed version of whataboutism, isn't it? Or can you show other languages that do prevent those other unnamed classes of bugs?
      - rob74 4y ago
        Er... no. I was simply saying that the many articles about how reliable Rust is and how many bugs it catches for you might lead to a false sense of safety. Nothing more, nothing less.
carnitine 4y ago
This seems like the opposite of a cautionary tale, if anything it makes Rust seem an even better choice.
hnarn 4y ago
> I needed a bit of palette cleanser This is a fun mistake. It’s “Palate cleanser”.
- gpderetta 4y ago
  Maybe they just want to drink solvent. A common reaction after dealing with very bad code for a while.
- rob74 4y ago
  Works with palette (as in painter's palette) too - start with a clean slate, use a whole different set of colors etc.
ekidd 4y ago
I have run "cargo fuzz" (based on the AFL fuzzer) over a binary-format parsing library I wrote, generating roughly a billion inputs. Here's what I learned: 1. Rust does not protect you at compile time against "index out of bounds" errors. If you want that, you'll want a dependently-typed language like Idris. Which still wouldn't help much in this case. 2. However, Rust catches index errors perfectly well at runtime, and performs a controlled panic. This does not result in a privilege escalation, but it may cause a denial of service. So fuzzing in (safe) Rust is normally a "lower stakes" activity. 3. "cargo fuzz" is super easy to use, and AFL is pretty amazing. 4. If you think you can parse complex, badly-documented low-level binary formats without ever having an index error, you're probably wildly overconfident. In the case of the minidump parser, it's worse: The data was generated by a crashing process, and in many cases, the data caused the crash. Let's look at what the author concludes: > And what did we screw up? Some legit stuff! It’s Rust code, so I am fairly confident none of the issues were security concerns, but they were definitely quality of implementation issues, and could have been used to at very least denial-of-service the minidump processor. A whole bunch of issues, probably none of them leading to security escalations. And unlike many C fuzzing experiences, it was largely painless: > By comparison I am absolutely thriving under “Yeah you can deterministically trip this assertion with this tiny input you can just check in as a unit test”. This happens because Rust catches most of these errors very early, using assertions in the standard library. So your fuzz reports often need to be tracked for only a few lines. TL;Dr: Parsing complex binary formats usually involves subtle bugs. Rust does not promise to catch index-out-of-bounds at compile-time, but it catches them at runtime. This makes fuzzing easy and productive. Overall, I'd call this a success story. The author underwent an inevitably humbling experience for low stakes under controlled conditions. And now the library can parse corrupted examples of an incredibly nasty format, with high confidence that the worst thing that will happen is a runtime error (not even a DoS).

by rob74 4y ago

rq1 4y ago

Well you’d have these bugs, plus the memory bugs in other languages.

fnord123 4y ago
They already did. Hence the rewrite from C++ to Rust.

proto_lambda 4y ago

You mean the tale of someone rewriting a very complex and fiddly software from scratch, having it work great in production, and then using the ecosystem's great tooling to easily find and eliminate even more bugs than what the language already protected them from?

kjksf 4y ago
The thing they rewrote also worked great in production. And fuzzing originated in C / C++ tools and is available for them as well, probably more diverse and mature than what is available in Rust. The point you did ignore was: Rust is being sold as magically making software safe and people selling that completely ignore the fact that logical bugs are also a thing. Which Rust evangelists find difficult to acknowledge because security is that one thing that Rust has going for it. So difficult that you would rather try to misdirect than to acknowledge that software written in Rust will crash. And when processing arbitrary user output, it'll crash badly when not written with care and fuzzed a lot. Kind of like C++.
- proto_lambda 4y ago
  > The thing they rewrote also worked great in production. It didn't for them, that's why they rewrote it. > Rust is being sold as magically making software safe and people selling that completely ignore the fact that logical bugs are also a thing. By whom? I don't think memory safety bugs are the only class of bugs, and neither do you, so who are you arguing against? > Which Rust evangelists find difficult to acknowledge because security is that one thing that Rust has going for it. Hard disagree. Rust also offers a solid type system, pain-free dependency management and all-around good tooling, just to name a few. It's much more than a "memory-safe C++" or whatever. > And when processing arbitrary user output, it'll crash badly If your definition of "badly" is "at a well-defined point, without any memory corruption", sure. But even here memory safety prevents what could be a much more painful debugging experience.
- rob74 4y ago
  What you said, although I would have probably phrased it less harshly :) But yes, my point was that there are a lot of enthusiastic articles about how Rust can prevent "whole classes of bugs", which mostly gloss over the fact that there are other classes of bugs that it doesn't prevent. Of course this doesn't mislead experienced developers, but I'm not so sure about novices or less technically inclined people.
  - tremon 4y ago
    which mostly gloss over the fact that there are other classes of bugs that it doesn't prevent That's nothing more than a technically-dressed version of whataboutism, isn't it? Or can you show other languages that do prevent those other unnamed classes of bugs?
    - rob74 4y ago
      Er... no. I was simply saying that the many articles about how reliable Rust is and how many bugs it catches for you might lead to a false sense of safety. Nothing more, nothing less.

carnitine 4y ago

This seems like the opposite of a cautionary tale, if anything it makes Rust seem an even better choice.

hnarn 4y ago

> I needed a bit of palette cleanser This is a fun mistake. It’s “Palate cleanser”.

gpderetta 4y ago
Maybe they just want to drink solvent. A common reaction after dealing with very bad code for a while.
rob74 4y ago
Works with palette (as in painter's palette) too - start with a clean slate, use a whole different set of colors etc.

ekidd 4y ago

I have run "cargo fuzz" (based on the AFL fuzzer) over a binary-format parsing library I wrote, generating roughly a billion inputs. Here's what I learned: 1. Rust does not protect you at compile time against "index out of bounds" errors. If you want that, you'll want a dependently-typed language like Idris. Which still wouldn't help much in this case. 2. However, Rust catches index errors perfectly well at runtime, and performs a controlled panic. This does not result in a privilege escalation, but it may cause a denial of service. So fuzzing in (safe) Rust is normally a "lower stakes" activity. 3. "cargo fuzz" is super easy to use, and AFL is pretty amazing. 4. If you think you can parse complex, badly-documented low-level binary formats without ever having an index error, you're probably wildly overconfident. In the case of the minidump parser, it's worse: The data was generated by a crashing process, and in many cases, the data caused the crash. Let's look at what the author concludes: > And what did we screw up? Some legit stuff! It’s Rust code, so I am fairly confident none of the issues were security concerns, but they were definitely quality of implementation issues, and could have been used to at very least denial-of-service the minidump processor. A whole bunch of issues, probably none of them leading to security escalations. And unlike many C fuzzing experiences, it was largely painless: > By comparison I am absolutely thriving under “Yeah you can deterministically trip this assertion with this tiny input you can just check in as a unit test”. This happens because Rust catches most of these errors very early, using assertions in the standard library. So your fuzz reports often need to be tracked for only a few lines. TL;Dr: Parsing complex binary formats usually involves subtle bugs. Rust does not promise to catch index-out-of-bounds at compile-time, but it catches them at runtime. This makes fuzzing easy and productive. Overall, I'd call this a success story. The author underwent an inevitably humbling experience for low stakes under controlled conditions. And now the library can parse corrupted examples of an incredibly nasty format, with high confidence that the worst thing that will happen is a runtime error (not even a DoS).