You say UNIX but then depend on many specifics of GNU/Linux ;) I haven’t actually run the code, but what I’ve spotted so far:
POSIX doesn’t mandate tools to live in any specific location, so you shouldn’t hardcode /usr/bin/. For example, on FreeBSD, echo and date are in /bin, and bash in /usr/local/bin
I’ll change the id and date invocations. As for the full path, there is a security reason behind them: if the user shadows them, she can run stuff under the effective privileged ownership of suc. By using the full path, I’m making sure there are no $PATH shenanigans going on. I should update the article to reflect that.
Yes, or rather, you can setuid it but Linux ignores it. Part of the reason is exactly this sort of $PATH problem. suc works around this by also shipping a C wrapper program that you can setuid and that calls the shell script.
Also, that program appears to have a bug, it fails to null-pointer terminate the argv array passed to execv.
But I think these kinds of nitpicks are holding back shell, e.g. most people don’t want to read id -unr
Agree with just using date, and not /usr/bin/date
The real answer (or at least the future facing one) should be that all Unixes support containers (OS virtualization), so you can build GNU tools or whatever you want inside them, without messing up the rest of the system
FreeBSD, Solaris, and Linux do, and probably a few others. I’d say that any others should get with the times
chroot might be technically sufficient for this case, but we also need common tools. From experience, it’s possible to do it with plain shell scripts, though it’s a lot of work, and some higher level abstractions are useful
Well, that’s rather dismissive, it’s like saying “meh, if you actually need to support other people than me…” :)
The article claimed to be a demonstration of modern UNIX and I only mentioned things that were genuinely broken on 2 of my UNIX systems (macOS & FreeBSD)
Also note that this isn’t portable either on GNU/Linux distributions, e.g. NixOS. I would say relying on $PATH is the best bet, and it’s the user’s job to be wary of the what’s going on in $PATH.
The danger is not to the user ! The user is the danger !
By playing with her $PATH, a user can execute arbitrary code owned by suc, which would let her e.g. edit the chat log (which is supposed to be append-only).
The last two businesses I have left, I’ve exported the custom emojis from slack (search GitHub for various scripts to achieve this easily) and then added a bunch to new $work’s slack upon joining. Not all of them of course, the in-jokes only work in the original place.
Is that functionally different from allowing inline images? Like can any user send any image as an “emoji” or is there some process by which emojis must be approved before they can be used?
Somewhat, yeah. Having shared, readily available reaction images allows for creating a community language, same as in-jokes or oft-repeated quotes. Using :sickos-yes: has a different flavor than :100: which has a different flavor than :clap-cowboy:, even tho they all mean “I agree with the statement”. But those meanings come from usage and situation, so if they have to be manually curated by each user, they won’t be used nearly as much.
Oh, do you mean “how are they added to slack?” I believe it’s configurable per server, but the servers I’m in allow any user to add a new emoji or create an alias for an existing emoji, and it supports various static and animated image formats.
The contents of the file aren’t filtered for terminal escape codes, so I think you can hack other folks terminals with this (assuming they’re tailing the file in a terminal).
On the dam, we make the choice to take that risk to get rich text. Any user can use pager that won’t interpret those code to guard against such an attack (e.g. less would do).
There are some terminals that use escape codes to open viewers for rich file types and other exciting things. It’s probably a good idea to permit only escape codes on an allow list (the ones for setting / resetting colour and bold are fairly innocuous).
I fell down this rabbit hole, and was unable to put what I’ve read into the article because it was too deep. I think it will need to go into an article of its own. I’ll do a deep dive into it someday.
But even on an old school VT100-compatible terminal, simply “forgetting” to close a color tag may be annoying to everybody.
One aspect I did not mention is that while anybody can try these attacks, they’d burn their reputations doing so, the channel file is append-only, so finding the culprit is trivial.
I think that indeed, a whitelist and resetting the terminal colors on each new line would be the best compromise between security and features. I know what the next patch to suc will be :)
But even on an old school VT100-compatible terminal, simply “forgetting” to close a color tag may be annoying to everybody.
Most things that permit colour codes fix that by resetting the colour at the end of any untrusted lines, so if you sanitise the input to contain no escape sequences other can colours, that’s pretty easy to handle.
One of the first C++ programs I remember writing in a high school computer lab was a chat app, it used two terminals though, one for printing one for typing, and it would just write to a text file on the school network windows (NT4) share… Supported some basic IRC slash commands, too
You say UNIX but then depend on many specifics of GNU/Linux ;) I haven’t actually run the code, but what I’ve spotted so far:
/usr/bin/. For example, on FreeBSD,echoanddateare in/bin, andbashin/usr/local/bindatedoesn’t need to support--iso-8601, some systems have-Ibut a portable way would be to use a format string:date +"%Y-%m-%dT%H:%M:%S %Z"(https://pubs.opengroup.org/onlinepubs/9699919799/utilities/date.html)iddoesn’t need to support--user --name --real, a portable way would beid -unr(https://pubs.opengroup.org/onlinepubs/9699919799/utilities/id.html)Fun idea though, I wouldn’t complain about replacing our company’s Slack with it. ;)
Thank you, that is really helpful.
I’ll change the id and date invocations. As for the full path, there is a security reason behind them: if the user shadows them, she can run stuff under the effective privileged ownership of suc. By using the full path, I’m making sure there are no $PATH shenanigans going on. I should update the article to reflect that.
This is a moot point on Guix, as the full path to the exact binary I need (e.g. /gnu/store/SOMEHASH-coreutils/bin/echo) is put into suc.sh when the package is installed (see https://gitlab.com/edouardklein/guix/-/blob/beaverlabs/beaver/packages/plan9.scm#L99).
Maybe I could use a configure-like step for other *nixes that would fix those paths at install time.
What do you mean by this? You can’t/shouldn’t setuid a bash script, right?
Yes, or rather, you can setuid it but Linux ignores it. Part of the reason is exactly this sort of $PATH problem.
sucworks around this by also shipping a C wrapper program that you can setuid and that calls the shell script.Also, that program appears to have a bug, it fails to null-pointer terminate the argv array passed to execv.
I have not tested this, but you could probably set PATH at the top of the script, such that any changes made by the untrusted user are overwritten.
Meh if you actually need portability, sure
But I think these kinds of nitpicks are holding back shell, e.g. most people don’t want to read
id -unrAgree with just using
date, and not/usr/bin/dateThe real answer (or at least the future facing one) should be that all Unixes support containers (OS virtualization), so you can build GNU tools or whatever you want inside them, without messing up the rest of the system
FreeBSD, Solaris, and Linux do, and probably a few others. I’d say that any others should get with the times
chroot might be technically sufficient for this case, but we also need common tools. From experience, it’s possible to do it with plain shell scripts, though it’s a lot of work, and some higher level abstractions are useful
Well, that’s rather dismissive, it’s like saying “meh, if you actually need to support other people than me…” :)
The article claimed to be a demonstration of modern UNIX and I only mentioned things that were genuinely broken on 2 of my UNIX systems (macOS & FreeBSD)
Also note that this isn’t portable either on GNU/Linux distributions, e.g. NixOS. I would say relying on
$PATHis the best bet, and it’s the user’s job to be wary of the what’s going on in$PATH.The danger is not to the user ! The user is the danger !
By playing with her $PATH, a user can execute arbitrary code owned by suc, which would let her e.g. edit the chat log (which is supposed to be append-only).
As for nix, one can patch the hardcoded path on install, as I did for guix: https://gitlab.com/edouardklein/guix/-/blob/beaverlabs/beaver/packages/plan9.scm#L99
Good article, but I laughed at this line
as on my slack servers, the most important feature is allowing custom emoji. On one server, we’re up to roughly 4k, and show no signs of stopping.
The last two businesses I have left, I’ve exported the custom emojis from slack (search GitHub for various scripts to achieve this easily) and then added a bunch to new $work’s slack upon joining. Not all of them of course, the in-jokes only work in the original place.
Maybe you could send emoji as sixel or kitty terminal graphics protocol pics.
Is that functionally different from allowing inline images? Like can any user send any image as an “emoji” or is there some process by which emojis must be approved before they can be used?
Somewhat, yeah. Having shared, readily available reaction images allows for creating a community language, same as in-jokes or oft-repeated quotes. Using
:sickos-yes:has a different flavor than:100:which has a different flavor than:clap-cowboy:, even tho they all mean “I agree with the statement”. But those meanings come from usage and situation, so if they have to be manually curated by each user, they won’t be used nearly as much.Oh, do you mean “how are they added to slack?” I believe it’s configurable per server, but the servers I’m in allow any user to add a new emoji or create an alias for an existing emoji, and it supports various static and animated image formats.
Damn, :sickos-yes: is a must have, I got to add this to the company chat.
The contents of the file aren’t filtered for terminal escape codes, so I think you can hack other folks terminals with this (assuming they’re tailing the file in a terminal).
There is indeed a small risk from displaying untrusted text on your terminal ! see e.g.: https://unix.stackexchange.com/questions/73713/how-safe-is-it-to-cat-an-arbitrary-file
On the dam, we make the choice to take that risk to get rich text. Any user can use pager that won’t interpret those code to guard against such an attack (e.g. less would do).
There are some terminals that use escape codes to open viewers for rich file types and other exciting things. It’s probably a good idea to permit only escape codes on an allow list (the ones for setting / resetting colour and bold are fairly innocuous).
I fell down this rabbit hole, and was unable to put what I’ve read into the article because it was too deep. I think it will need to go into an article of its own. I’ll do a deep dive into it someday.
You are right, some terminals do have advanced features accessible via escape codes. Here is iTerm2’s for example: https://iterm2.com/documentation-escape-codes.html https://iterm2.com/documentation-images.html
But even on an old school VT100-compatible terminal, simply “forgetting” to close a color tag may be annoying to everybody.
One aspect I did not mention is that while anybody can try these attacks, they’d burn their reputations doing so, the channel file is append-only, so finding the culprit is trivial.
I think that indeed, a whitelist and resetting the terminal colors on each new line would be the best compromise between security and features. I know what the next patch to suc will be :)
Most things that permit colour codes fix that by resetting the colour at the end of any untrusted lines, so if you sanitise the input to contain no escape sequences other can colours, that’s pretty easy to handle.
FSVO “small”
Yeah, the more I look into it, the more I feel I should address it and stop trusting the terminal emulators.
Here is a great rundown from ~20 years ago: https://marc.info/?l=bugtraq&m=104612710031920&w=2
I wouldn’t be surprised if the vuln has been reintroduced since then. I’ll provide some code to sanitize the file.
Thank you. I enjoyed this article tremendously, and learned (and re-learned) a lot. Inspiring.
I’m glad you liked it, thank you for your kind words.
/usr/bin/true?/usr/bin/echo???Besides being strange places to keep those, at least one is usually a built-in
Speaking of shells & Mattermost, Matterhorn is such a good TUI client that I wish it expanded beyond Mattermost.
One of the first C++ programs I remember writing in a high school computer lab was a chat app, it used two terminals though, one for printing one for typing, and it would just write to a text file on the school network windows (NT4) share… Supported some basic IRC slash commands, too
More than 5 lines…. Probably less than 50, though
Great article, I like how far you took it! i.e. having media, not just text
Personally I think shell-style programming doesn’t have to be permanently coupled to the terminal – that is limiting
Oils is exploring that direction with “the headless shell” - https://www.oilshell.org/blog/2023/06/release-0.16.0.html#headless-shell-screenshots
UI tip: tweak your CSS to set monospace typefaces at 0.9x of baseline, it prevents text set thusly from being too prominent.
It took me a while to get around to it but I just added
to the CSS.
Thanks ! :)