I think this interview with the uutils project lead https://www.youtube.com/watch?v=5qTyyMyU2hQ is fairly telling about the motivation behind the project. He mentions that he's not motivated by memory safety and that the GNU coreutils don't have security problems. The discussion gets interesting when the hosts start talking about software licensing. The GNU coreutils are of course GPL licensed, while uutils is MIT licensed. The lead says that he doesn't care about how the project is licensed, as long as it's OSI-approved, and that talking about software licenses is a waste of time. However, at one point (while the hosts are talking about reasons why a user might choose uutils instead of the GNU coreutils), one of the hosts refers to a discussion they'd had with the lead prior to the recorded interview about how car companies were using uutils for "compliance reasons", and asks if that's related to some sort of EU regulation about memory safety. The lead has to correct him, and says that the car companies weren't concerned about memory safety compliance, but GPL compliance. Combined with other statements he makes about purposely not looking at the original coreutils code to avoid any claims of the implementation being "tainted" by GPL code (seems like a lot of work for someone who doesn't care about software licensing), it seems like a major motivating factor behind the uutils project is to create a permissively licensed drop-in replacement to the GNU coreutils.

I'd say misplaced evangelism.

ls, chgrp, chown, etc are applications that the current user will use to interactively work with them. Or maybe use in a shell script. They are not to be exposed to malicious inputs, so any bugs are usually not security problems, because you can't really do anything that the user couldn't do anyways. There is no security boundary, so nothing to secure there.

However, if you e.g. write your webserver as a shell script or using shell commands you are doing it wrong and you deserve the evil things an attacker does to you.

Also, very often, the insecurity is codified in the relevant standards such as POSIX, so you cannot really fix anything without breaking everything. E.g. newlines and various kinds of whitespace characters in filenames are a huge pain to handle safely in shell commands and especially shell scripts, if possible at all. Because shells do split things at any whitespace (unless quoted properly, which is hard to impossible to do) and shell commands usually separate their stdin/stdout at newlines (unless you know about -print0 and everything in your pipe does as well...). None of this is fixed by rust, everything could be fixed by throwing away existing standards first, but then the language doesn't matter.

> ls, chgrp, chown, etc are applications that the current user will use to interactively work with them. Or maybe use in a shell script. They are not to be exposed to malicious inputs, so any bugs are usually not security problems, because you can't really do anything that the user couldn't do anyways. There is no security boundary, so nothing to secure there.

I dunno, I'd expect that you could

  ls -l untrusted.exe
  mv untrusted.exe untrusted.exe.donotrun
  chmod 600 untrusted.exe.donotrun
  sha256sum untrusted.exe.donotrun

without anything bad happening. That said, I'd like some evidence that GNU's coreutils aren't already safe; I suspect that their limited scope means there's minimal exposure even when operating on untrusted inputs (note that in my example there, only hashing the file actually involves its contents).

For the ls one, the name might contain characters that do bad things. A common prank in uni was to have a filename with an ascii BEL character, that will beep when you do ls in that directory. Terminal escape sequences can do a lot more. However, I think modern ls filters that, except with some POSIXLY_CORRECT environment variables set.

That mv and chmod might operate on a whole different file due to a symlink or hardlink being in place, and due to the inherent race condition between all those operations that just use the file name. Also, mv might overwrite an existing file.

sha256sum will run escaping on the filename output, thereby making automated comparisons fail if you are unaware of that feature. On the other hand, when turning off escaping with -z, you need to know how to handle the \0 separator.

More intetesting adversarial inputs would be very long filenames, filenames with embedded \0x0, \x0A \x0D, BOM, etc.

Not that GNU coreutils must be vulnerable to this. But I suppose they are explicitly hardened against such inputs, despite the C language not providing any guard rails.

There have been CVEs in core utils. I am not aware of any that Rust would prevent.