4 ms·
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
by Zamiel_Snawley 3y 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.
- jackmott42 3y agoOne 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.
- c_crank 3y agoA whole laundry list of languages have stricter typing than C, garbage collected or not.
- Zamiel_Snawley 3y agoAnd 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.
- c_crank 3y agoAda never had the same level of marketing power towards engineers that Mozilla came up with. GNAT still came out well before Rust did.
- Zamiel_Snawley 3y agoI 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.
- c_crank 3y agoDoD 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.
- dragonwriter 3y ago> The last time the government tried to set a computing language standard, we got COBOL, Ada, actually (well, that might not be the last time, but it is certainly much more recent than COBOL.) COBOL and JOVIAL were roughly concurrent – both efforts started in 1959, I believe – but the effort that culminated in Ada started in the mid-1970s.
- c_crank 3y agoI should have clarified that I meant a universal standard. COBOL was meant to create a common language across business and government, while Ada was meant to just consolidate a language across DoD projects. Ada is a much better language than COBOL, but I think that adoption of even a good language across those ecosystems will only succeed when it is adopted from the ground up.
- WirelessGigabit 3y agoDo 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.
- Zamiel_Snawley 3y agoI'm not sure, I only see static analysis and fuzzing workflows in the CI on GitHub [1]. [1] https://github.com/millert/sudo/actions https://github.com/millert/sudo/actions
- rnijveld 3y agoWe 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).