6 ms·

It seems like I'm probably preaching to the choir, but what really is the attack surface with coreutils? I can't imagine there have been a lot of pwns as a resu

It seems like I'm probably preaching to the choir, but what really is the attack surface with coreutils? I can't imagine there have been a lot of pwns as a result of the `date` command.

denkmoon 1y ago
To play devil's advocate, who knows what kind of madness people are handing off to subprocess.run(["date"]) et al. They shouldn't, but I'd bet my last dollar it's out there.
ls65536 1y ago
I can certainly understand it for something like sudo or for other tools where the attack surface is larger and certain security-critical interactions are happening, but in this case it really seems like a questionable tradeoff, where the benefits in this specific case are abstract (theoretically no more possibility of any memory-safety bugs) but the costs are very concrete (incompatibility issues; and possibly other, new, non-memory-safety bugs being introduced with new code). EDIT: Just to be clear, I'm otherwise perfectly happy that these experiments are being done, and we should all be better off for it and learn something as a result. Obviously somebody has assessed that this tradeoff has at least a decent probability of being a net positive here in some timeframe, and if others are unhappy about it then I suppose they're welcome to install another implementation of coreutils, or use a different distro, or write their own, or whatever.
- johnisgood 1y ago
  > "sudo" Hence "doas". OpenBSD has a lot of new stuff throughout the codebase. No need for adding a bloated dependency (e.g. Rust) just because you want to re-implement "yes" in a "memory-safe language" when you probably have no reasons to.
  - deleted 11mo ago
    [deleted]
- JuniperMesos 1y ago
  I'd prefer it if all software was written in languages that made it as easy as possible to avoid bugs, including memory-safety bugs, regardless of whether it seems like it has a large attack surface or not.
- pdimitar 11mo ago
  I view `uutils` as a good opportunity to get rid of legacy baggage that might be used by just 0.03% of the community but has to sit there and it impedes certain feature adding or bug fixing. F.ex. `sudo-rs` does not support most of what the normal `sudo` does... and it turned out that most people did not need most of `sudo` in the first place. Less code leads to less bugs.
mort96 1y ago
Untrusted input is often stored in files. Coreutils tools are often used to operate on those files. As an obvious example, I sometimes download files from the Internet, then run coreutils sha256sum or the like on those files to verify that they're trustworthy. That means they're untrusted at the time where I use them as input to sha256sum. If there's an RCE in sha256sum (unlikely, but this is a thought experiment to demonstrate an attack vector), then that untrusted file can just exploit that RCE directly. If there's a bug in sha256sum which allows a malicious file to manipulate the result, then a malicious file could potentially make itself look like a trusted file and therefore get past a security barrier. Maybe there's no bug in sha256sum, but I need to base64 decode the file before running sha256sum on it, using the base64 tool from coreutils. If you use your imagination, I'm sure you yourself can think up plenty more use cases where you might run a program from GNU coreutils against untrusted user input. If it helps, here's a Wikipedia article which lists all commands from GNU coreutils: https://en.wikipedia.org/wiki/GNU_Core_Utilities#Commands https://en.wikipedia.org/wiki/GNU_Core_Utilities#Commands EDIT: To be clear, this comment is only intended to explain what the attack surface is, not to weigh in on whether rewriting the tools in Rust improves security. One could argue that it's more likely that the freshly rewritten sha256sum from uutils has a bug than that GNU sha256sum has a bug. The statement "tools from coreutils are sometimes used to operate on untrusted input and therefore have an attack surface worth exploring" is not the same as the statement "rewriting coreutils in Rust improves security". Personally, I'm excited for the uutils stuff, but not primarily because I believe it alone will directly result in significant security improvements in Ubuntu 25.10.
- pantalaimon 1y ago
  But if there is a bug in the date command that prevents security updates from being installed, you've got your vulnerability right there. Rust is not a silver bullet.
  - mort96 1y ago
    Please read my edit.
  - viraptor 1y ago
LtWorf 1y ago
I reported a segfault in "tac" a number of years ago.
ajross 1y ago
You don't attack coreutils. You attack the scripts. In this case it was an update script that failed because of an incompatibility. It's not too hard at all to imagine one failing in an exploitable way. Honestly, Rust-related hilarity aside, this project was a terrible, terrible idea. Unix shell environments have always been ad hoc and poorly tested, and anything that impacts compatibility is going to break historical code that may literally be decades old. See also the recent insanity of GNU grep suddenly tossing an error when invoked as "fgrep". You just don't do that folks.
- johnny22 1y ago
  and yet coreutils continues to receive updates in ways that could break things.
- collinfunk 1y ago
  > See also the recent insanity of GNU grep suddenly tossing an error when invoked as "fgrep". You just don't do that folks. The 'fgrep' and 'egrep' didn't throw errors, it would just send a warning to standard error before behaving as expected. Those commands were never standardized, and everyone is better off using 'grep -F' and 'grep -E' respectively.
  - ajross 1y ago
    > didn't throw errors, it would just send a warning to standard error Noted without comment. Except to say that I've had multiple scripts of my own break via "just" discovering garbage in the output streams. > Those commands were never standardized "Those commands" were present in v7 unix in 1979!
    - larusso 1y ago
      I think he means POSIX. Didn’t check but in some cases posix only covers some options a tool provides not all. It’s a hard lesson I learned while keeping shell scripts portable between Linux and macOS.
wvh 1y ago
A thousand badly written shell scripts might disagree.

It seems like I'm probably preaching to the choir, but what really is the attack surface with coreutils? I can't imagine there have been a lot of pwns as a result of the `date` command.

denkmoon 1y ago

To play devil's advocate, who knows what kind of madness people are handing off to subprocess.run(["date"]) et al. They shouldn't, but I'd bet my last dollar it's out there.

ls65536 1y ago

I can certainly understand it for something like sudo or for other tools where the attack surface is larger and certain security-critical interactions are happening, but in this case it really seems like a questionable tradeoff, where the benefits in this specific case are abstract (theoretically no more possibility of any memory-safety bugs) but the costs are very concrete (incompatibility issues; and possibly other, new, non-memory-safety bugs being introduced with new code). EDIT: Just to be clear, I'm otherwise perfectly happy that these experiments are being done, and we should all be better off for it and learn something as a result. Obviously somebody has assessed that this tradeoff has at least a decent probability of being a net positive here in some timeframe, and if others are unhappy about it then I suppose they're welcome to install another implementation of coreutils, or use a different distro, or write their own, or whatever.

johnisgood 1y ago
> "sudo" Hence "doas". OpenBSD has a lot of new stuff throughout the codebase. No need for adding a bloated dependency (e.g. Rust) just because you want to re-implement "yes" in a "memory-safe language" when you probably have no reasons to.
- deleted 11mo ago
  [deleted]
JuniperMesos 1y ago
I'd prefer it if all software was written in languages that made it as easy as possible to avoid bugs, including memory-safety bugs, regardless of whether it seems like it has a large attack surface or not.
pdimitar 11mo ago
I view `uutils` as a good opportunity to get rid of legacy baggage that might be used by just 0.03% of the community but has to sit there and it impedes certain feature adding or bug fixing. F.ex. `sudo-rs` does not support most of what the normal `sudo` does... and it turned out that most people did not need most of `sudo` in the first place. Less code leads to less bugs.

mort96 1y ago

Untrusted input is often stored in files. Coreutils tools are often used to operate on those files. As an obvious example, I sometimes download files from the Internet, then run coreutils sha256sum or the like on those files to verify that they're trustworthy. That means they're untrusted at the time where I use them as input to sha256sum. If there's an RCE in sha256sum (unlikely, but this is a thought experiment to demonstrate an attack vector), then that untrusted file can just exploit that RCE directly. If there's a bug in sha256sum which allows a malicious file to manipulate the result, then a malicious file could potentially make itself look like a trusted file and therefore get past a security barrier. Maybe there's no bug in sha256sum, but I need to base64 decode the file before running sha256sum on it, using the base64 tool from coreutils. If you use your imagination, I'm sure you yourself can think up plenty more use cases where you might run a program from GNU coreutils against untrusted user input. If it helps, here's a Wikipedia article which lists all commands from GNU coreutils: https://en.wikipedia.org/wiki/GNU_Core_Utilities#Commands https://en.wikipedia.org/wiki/GNU_Core_Utilities#Commands EDIT: To be clear, this comment is only intended to explain what the attack surface is, not to weigh in on whether rewriting the tools in Rust improves security. One could argue that it's more likely that the freshly rewritten sha256sum from uutils has a bug than that GNU sha256sum has a bug. The statement "tools from coreutils are sometimes used to operate on untrusted input and therefore have an attack surface worth exploring" is not the same as the statement "rewriting coreutils in Rust improves security". Personally, I'm excited for the uutils stuff, but not primarily because I believe it alone will directly result in significant security improvements in Ubuntu 25.10.

pantalaimon 1y ago
But if there is a bug in the date command that prevents security updates from being installed, you've got your vulnerability right there. Rust is not a silver bullet.
- mort96 1y ago
  Please read my edit.
- viraptor 1y ago

LtWorf 1y ago

I reported a segfault in "tac" a number of years ago.

ajross 1y ago

You don't attack coreutils. You attack the scripts. In this case it was an update script that failed because of an incompatibility. It's not too hard at all to imagine one failing in an exploitable way. Honestly, Rust-related hilarity aside, this project was a terrible, terrible idea. Unix shell environments have always been ad hoc and poorly tested, and anything that impacts compatibility is going to break historical code that may literally be decades old. See also the recent insanity of GNU grep suddenly tossing an error when invoked as "fgrep". You just don't do that folks.

johnny22 1y ago
and yet coreutils continues to receive updates in ways that could break things.
collinfunk 1y ago
> See also the recent insanity of GNU grep suddenly tossing an error when invoked as "fgrep". You just don't do that folks. The 'fgrep' and 'egrep' didn't throw errors, it would just send a warning to standard error before behaving as expected. Those commands were never standardized, and everyone is better off using 'grep -F' and 'grep -E' respectively.
- ajross 1y ago
  > didn't throw errors, it would just send a warning to standard error Noted without comment. Except to say that I've had multiple scripts of my own break via "just" discovering garbage in the output streams. > Those commands were never standardized "Those commands" were present in v7 unix in 1979!
  - larusso 1y ago
    I think he means POSIX. Didn’t check but in some cases posix only covers some options a tool provides not all. It’s a hard lesson I learned while keeping shell scripts portable between Linux and macOS.

wvh 1y ago

A thousand badly written shell scripts might disagree.