Re:Why you should, actually, rewrite some of it in Rust
by jcelerier on Wednesday July 12, 2017 @01:33PM
(#14754559)
You would get 2. and 3. as runtime panic in C if you used sanitizers.
Re:Why you should, actually, rewrite some of it in Rust
by the_why_of_y on Wednesday July 12, 2017 @06:39PM
(#14757285)
You would also get additional attack surface if you used sanitizers, because they were designed as debugging tools, not for production deployment.
Re:Why you should, actually, rewrite some of it in Rust
by bandook_raja on Wednesday July 12, 2017 @12:59PM
(#14754233)
I think you aren't understanding what parent comment is trying to say. No one is saying rust isn't better than C in some respects, instead, you were comparing Rust + Fuzzing with C and he implied that you should at least use C + AFL if you want to compare properly otherwise it's just BS.
Re:Why you should, actually, rewrite some of it in Rust
by eridius on Wednesday July 12, 2017 @01:29PM
(#14754508)
It's a pointless comparison. Fuzzers don't catch everything. What's important is the type of issue that the fuzzers do reveal, because that gives a hint as to how severe the uncaught issues may be.
You can find a list of my vobsub bugs in the Rust Fuzz Trophy Case: https://github.com/rust-fuzz/trophy-case They are:
1. The shift overflow: This was harmless in both C and Rust, I believe.
2. The arithmetic overflow: This was a runtime panic in Rust, resulting in a clean crash. In C, this might have been exploitable with a complex enough attack.
3. The three "invalid slice" errors. All of these were clean runtime panics in Rust, and I'm pretty sure that at least two of them would have been exploitable in C with enough work.
So Rust has a couple of advantages here. Out of 5 errors found by the fuzzer, the worst thing that could happen in Rust would have been crashing the program in a controlled fashion. In C, we would have been looking at memory corruption and quite possibly escalation.
Secondly, Rust's runtime checks actually make fuzzers work better. Even simple checks like "is the end index of this slice great >= to the beginning index?" tend to catch problems almost as soon as they occur.