Security issues found within rust-coreutils
30 points by hugoarnal
30 points by hugoarnal
I sampled > 10 random issues. Most of them involve symlinks (these are always fun, ha?). quite a few non-UTF-8 handling issues. Some of the issues seem ... kind of basic, even surprising. E.g... discarding errors seems like a easy "don't do that" kind of a bug.
Don't want to be too harsh, as it's always easy to judge, but it does seem like not at level of maturity required. Which is a check-and-egg problem too.
BTW. What's on my mind immediately is how feasible it is to do some kind of a file-system-centring fuzzing-like suite, to run new and original implementations side by side to detect mismatches automatically.
I find it very disturbing that Ubuntu shipped this in LTS. Yes, the found issues have presumably been fixed, but the amount of very basic issues that were found casts a bad look on this project.
I find it very disturbing that Ubuntu shipped this in LTS.
I'm not so sure. It was shipped first in 25.10, has had a security audit (and addressed issues) and continues to use GNU coreutils for commands with known showstoppers.
An LTS's stability is part "does this work", and part "how costly is this to support for 5+ years".
GNU coreutils has no LTS release, which means Canonical defacto provide that LTS for 5+ years.
Since Canonical are already funding development of rust-coreutils, I can see why they might want to avoid those coreutils maintenance costs too. That will allow them to spend effort in other places.
had a security audit (and addressed issues) and continues to use GNU coreutils for commands with known showstoppers.
The security audit found so many issues that the uutils team were unable to fix them all before the next LTS deadline They were only able to fix ~half. And Ubuntu☨ decided to ship anyway.
As ~mxey mentions the issues found reveal the code has a long way to go to reach maturity. f/e take a look at https://github.com/uutils/coreutils/issues/10011. The bug is that cp creates the files with the broad permissions only to reduce them later! Similar problem with mkfifo on https://github.com/uutils/coreutils/issues/10020 !!
Yes, uutils has done tons of good work (writing a test suite from scratch as GNU coreutils has little tests AFAIU), is good citizen as it collaborates with GNU coreutils. I think long term uutils is going to be a success.
But going ahead with the LTS realize looks like a C-level (uutils adoption is happening because the VP of engineering IIRC) want to tick off a checkbox to show 'results' now, consequences be damned. Treating Ubuntu user's like their QA. More bad press is likely to come out of this decision, let's hope the peanunt gallery doesn't point the finger at the uutils project or Rust. I wish they would have dropped uutils from the LTS release and continue their approach of shipping it on non-LTS releases and target the next LTS release instead.
☨ I want to emphasize that the party behaving irresponsibly here is Ubuntu, not the uutils maintainer, who is doing the best they can.
Interesting that they assigned a CVE to that one. I agree that it is a serious issue that should be fixed (and assigning a CVE may accomplish that), but I fail to see how someone could exploit this.
You'd probably first have to cause an error on the backup medium, wait for the backup script to run, wait untill the original is deleted (or cause a failure on the source), and then you didn't accomplish anything extra, other than perhaps the admin not noticing the backup failed. If the tool notices the error the backup would've still failed, and the data would still be lost...
I can't help but feel that uutils/coreutils is going about this the wrong way.
They're attempting a breadth-first conversion where they have dozens of partially-implemented replacements for the GNU coreutils, but this introduces a lot of compatibility risk because the GNU coreutils are mostly unspecified and untested. And the code they've got does not fill me with confidence, it's full of unwrap() which leads to bug reports like https://github.com/uutils/coreutils/issues/5371 plus they're doing the "hackathon tech demo" thing of mixing tests into the implementation source file.
Ideally there'd be more of a focus on a small batch of tools, getting those rock solid, and then moving on to the next batch. It's not like there's an urgent need to prioritize migrating in one big go, the system runs fine with a mixture of uutils and GNU.
plus they're doing the "hackathon tech demo" thing of mixing tests into the implementation source file.
This is not unusual in Rust. Unit tests are usually in the source file where the code lives. This has multiple reasons, among them visibility.
Ideally there'd be more of a focus on a small batch of tools, getting those rock solid, and then moving on to the next batch. It's not like there's an urgent need to prioritize migrating in one big go, the system runs fine with a mixture of uutils and GNU.
I think it's difficult to set priorities on volunteer contributions in OSS. I would find it difficult to reject a PR with a 90% implementation of ls until cp was 100% done. After all, many early adopters would be happy with 90% done, and there's value in getting early adopters actually using tools, in part to identify the remaining gap.
Distributions such as Ubuntu are well placed to select the subset that are sufficiently compatible.