4 ms·

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 sc

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.

yjftsjthsd-h 2y ago
> 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).
- thyristan 2y ago
  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.
- nine_k 2y ago
  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.
deleted 2y ago
[deleted]

yjftsjthsd-h 2y ago

> 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).

thyristan 2y ago
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.
nine_k 2y ago
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.

deleted 2y ago

[deleted]