Hacker News new | ask | show | jobs
by Zamiel_Snawley 1090 days ago
As others have mentioned, there is a long list of sudo CVEs that are unrelated to memory safety. I didn't see it mentioned in the article, but I hope that they have mined the CVEs for tests to ensure they don't accidentally reintroduce a known vulnerability. I was also surprised to see no mention of tests originally written for ogsudo, surely there are some?

Overall, I appreciate the rewrite-it-in-rust 'movement', I think it is an excellent learning opportunity for people who may not otherwise bother with learning the details of the foundations of our modern systems. And, as in this case, taking a detailed look at the original can improve the original.

3 comments

Do you know if sudo uses negative tests for their CVE fixes?

If they are written in such a way that they are portable (i.e. execute sudo, send mangled data, inspect response) it shouldn't be too hard to run it against the new version.

At least that is what I try to practice in fixing all kinds of bugs. Write test that proves the bug, fix the bug, write test that proves bugfix works, invert the test that proves the bug.

I'm not sure, I only see static analysis and fuzzing workflows in the CI on GitHub [1].

[1] https://github.com/millert/sudo/actions

One of the famous non memory safety bugs in sudo recently was related to using a sigil, which Rust would have prevented because the natural and easy solution in Rust for those use cases is an Enum/Sum Type.

Which is to say that Rust has safety features beyond just what we are used to from garbage collected languages. Sum types, stricter typing, data race protections, etc.

A whole laundry list of languages have stricter typing than C, garbage collected or not.
And yet, Rust is being taken seriously in many places where those languages have been unable to displace C. I wonder if it hadn't taken 15 years for a FOSS Ada compiler to become available, maybe it would have taken off.
Ada never had the same level of marketing power towards engineers that Mozilla came up with. GNAT still came out well before Rust did.
I suppose my point was that Ada had missed it's shot-by the time GNAT came out, the buzz of an exciting new language expired before people could easily use it.

I'm not familiar with the marketing that Mozilla did, but whatever they did it does seem to have been effective. However, I do think that the Ada mandate by the DoD would be equivalent or more effective in kick-starting an ecosystem.

DoD software and the commercial / FOSS world rarely intersect. The last time the government tried to set a computing language standard, we got COBOL, so it's probably for the better such a thing isn't tried again.

The marketing Mozilla employees have came up with is creating a Categorical Imperative for using Rust. The person in the comments section of a C project or any CVE bug will be saying, this would never have happened if this was written in Rust, why aren't you writing this in Rust? The moral thing to do was to write it in Rust! And a lot of software engineers are eager to think and talk like this, because it gives them something more exciting in their lives beyond writing bean counters for selling widgets. Pure functional languages already had a bit of that attitude, but I don't think it caught on nearly so much because actually writing pure functional code is very difficult even for most engineers.

We did indeed look at and are still looking at the list of CVEs where sudo takes part right now. However, many of the bugs are through one way or another not applicable for our implementation (yet). For example CVE-2014-0106 is only applicable when env_reset is disabled, but we purposely do not support that mode. Or take for example CVE-2023-28487 which concerns sudoreplay, but right now we have no plans to add that functionality.

Sudo does have a suite of regression tests, but they mostly test specific implementation details which makes it hard to port to our codebase. Our test suite tests against the integrated artifact, which allows the easy switching between the two implementations (and also allowed us to find a few bugs in the original sudo).