11 ms·

> 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 expo

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

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.