I'm pretty sure the OP is intentionally not doing this because piping commands/things-from-the-internet into "bash" (or anything else) is generally considered bad practice.
For me, I'm all for this. Anyone that is aware of the security implications is extremely likely aware of how to make the conversion like you've provided. In that case, no reason to tell people, because they already know. But it's not a great thing to tell noobies to do because they will get burned. So don't tell them. As they advance they'll naturally learn about this feature. And hopefully they have learned the implications by the time they learn how to do this.
> I'm pretty sure the OP is intentionally not doing this because piping commands/things-from-the-internet into "bash" (or anything else) is generally considered bad practice.
It’s generally considered bad practice only for bash and similar commands that execute their input. It’s not a bad practice at all for commands that just display or transform their input, like `man`, `less`, `ffmpeg`, etc.
> ffmpeg
There is certainly a few hundered exploitable vectors in that program alone... to say nothing of the rest.
When in doubt, spin up a VM to run the random untrusted thing -- And then go read its mailing list/issue tracker for known VM escaping exploits. I have a machine setup to test malware, so I just hit my "airgap" switch to isolate the system from my network once the questionable code is in place and ready to run (potentially amok). Study-up about ARP-poison attacks, and remember ARP does not transit to upstream routers/switches (Y "combinate" your network for fun and profit).
Before you assume non malicious simple text output, consider "ANSI" escape code complexity as an intrusion vector for whatever terminal you run. I've got "0-days" for this going back to MSDOS: ANSI Bomb => arbitrary CMD entry. You don't have to take my word for it, your terminal of choice is most certainly vulnerable to some ANSI/escape code related exploit, look it up.
This is why I spin up a VM whenever I want to look at an image. The risk is too great. Even text files, after all we never know if there's a zero day in the UTF-8 decoder. Better safe than sorry.
Wait a minute I just realized there could be a zero day in the VM hypervisor too. I guess I'll just have to buy a fresh Raspberry Pi for each file I want to open.
Man on Linux runs groff, which (like the original nroff/troff) is a fully general macro processor in addition to being a typesetting system. I wouldn’t bet on it not being able to launch subprocesses, or especially on it having no overflows and such on untrusted input. I’m not even sure about OpenBSD’s much more limited mandoc.
(Also, I don’t know about ffmpeg as it is somewhat more rare to have it be public-facing, but there have definitely been exploits against ImageMagick, usually targeted at websites using it to process user input.)
There's not much difference doing a pipe or using and intermediary file and "excecuting" that straight away. There's no manual step in the documentation there to read the output before it's run.
There definitely is a difference. See [1] (or [2] since the original site has misconfigured TLS). Long story short, using some fairly trivial heuristics, a malicious server could change its response when it detects its output being piped to a shell rather than saved to a file. Thus, a security-minded person downloading the file (who could inspect it) would be given a clean copy, but someone less security-minded piping it straight to bash would be given the malicious copy. The security-minded person wouldn't be able to warn people not to pipe the script to a shell, since it appears safe.
This is extremely specifically is about detecting that Bash is pulling on the stream, by using it's line by line interpretation to do a timing attack. It's not clear there's a timing difference between pushing the stream to disk versus pushing the stream to man, since it seems fairly likely that man would read the entire file into memory before operating on it (at least modern man)
This is not accurate. If the download gets interrupted bash will execute the partial line. That means `rm -r /tmp/foo.ext` or `rm -r ${HOME}/.tmp_config` can execute as `rm -r /`.
This can be mitigated by wrapping the script, but clearly no one is looking at the code so this isn't really verified anyways. And it's not like we see that all the time.
Edit:
But my main point is about habits. There's the concern mananaysiempre brings up[0], but either way, it is best to be in good habits.
I think you've missed the context of my comment. We're talking about `curl | man` not `curl && man`. You're right, `&&` doesn't have that risk. But `|` sure does.
On modern, sane systems (meaning those running GNU coreutils, which doesn't include os x iirc), rm -rf / will refuse to run unless --no-preserve-root is also specified.
This is to all the people saying no difference between downloading and running right away
If the download gets interrupted bash will execute the partial line. That means `rm -r /tmp/foo.ext` or `rm -r ${HOME}/.tmp_config` can execute as `rm -r /`. This can be mitigated by wrapping the script. Best way to do this is wrap the whole script into a function and then execute at the last line[0]. Oh, and you can detect `curl|bash` server side[1]
I agree that it's a risk to pipe to sh but that's not what we're doing here, and I'd hope that most of the people aren't saying there's no difference between piping to man and piping to sh.
Piping to your shell and piping to `man` are not the same thing.
The really dangerous thing is copy/pasting from a browser to your terminal. Always do Ctrl-X Ctrl-E to open an editor, paste it in there, then inspect it before saving/closing the editor to run the command.
No, they're not the same thing! It's not piping to your shell! The shell's single purpose is to execute code. Man is not supposed to do that and it would be considered a huge security issue if it could. In any case, how would you check the downloaded file? With a text editor? Are you sure that can't result in arbitrary code execution?
There is no practical difference. "Nobody" will inspect the man page using a different viewer first. So if I download to disk and then view via man or directly via man is no difference.
A shell script one might inspect first using some viewer. While only few probably do.
I only recently learned of it myself despite being on nix for over a decade and reading many advanced bash shortcut blogs. IDK why it isn't well known.
Note: this can be tricky depending on where it goes in your zshrc. If you use a plugin manager (like Sheldon) then this should be above that. I ended up with this and it works well on OSX and linux
autoload -U edit-command-line
# Emacs style (<C-x><C-e>)
zle -N edit-command-line
# make sure `set -o vi` is above this line
bindkey '^xe' edit-command-line
bindkey '^x^e' edit-command-line
# (VIM) Use visual mode
bindkey -M vicmd v edit-command-line
I'm sorry, your argument is... what exactly? That we shouldn't take simple or even trivial preventative measures that also reduce other potential problems because we... haven't seen anybody abuse such a thing before? Really?
What a terrible argument. Not it's trivial to resolve. Why not just fix things that we know are problems or can lead to serious problems instead of waiting for it to become a problem where it'll then be FAR more work to clean it up?
Seriously, you're a human, not a bug. You have the ability to solve things before they become problems. Use it.
While I'm not sure of a specific example, I feel quite confident in saying that this has been done before.
Read elsewhere. Piping can be dangerous if there's a disconnect. You can also detect piping server side. Piping is strictly worse. Convenient, yes, but 99% of the commands can non-streams and no difference for the end user who is copy pasting it.
It appeared as a rhetorical question used to rebut the claim. Maybe I misinterpreted it. Fair. But that is a possible interpretation.
But as you can see elsewhere, we shouldn't pipe streams into anything. It's just not hard to avoid this. A few extra characters and you're good to go. Let's take rust for example. Users are copy pasting anyways
They give
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
For user experience, it is till a one liner, but it is infinitely better. Still has some risks, but a lot less. (at least rust does wrap the install so you don't run the risk of partial line execution) And it gives the user a way to verify that the file was correct if they provide a checksum.
There's just no good reason to not do this. We especially shouldn't be teaching noobies to pipe streams into any command. Let's be real, most people don't know linux well, even if they use linux.
> But as you can see elsewhere, we shouldn't pipe streams into anything.
Firstly, I'll assume you mean untrusted streams since if you didn't mean that, we might as well throw out UNIX entirely.
Even given that caveat though, I disagree. Downloading an image and then converting that image into another format is not a case where there's a material improvement in security when making temporary files instead of using pipes. I'd argue in some cases it may have the opposite effect.
It's indicative of the lack of rationale on this more general case that you selected an example where the piping is into sh here.
I agree with all of your points about piping into sh, just not that we can turn that into a general principal. It's OK if we have different best practices between these two cases.
This kind of advice taken by a laymen or junior dev can cause problems, because the second you put the file on disk there's a risk you won't clean up that content, which for an automated system will ultimately bring it down when the disk fills up. In addition, if the information downloaded is sensitive, you are creating a security problem if you are intentionally writing it on disk even if you do clean it up later, as filesystem data remains persistent after unlink.
For me, I'm all for this. Anyone that is aware of the security implications is extremely likely aware of how to make the conversion like you've provided. In that case, no reason to tell people, because they already know. But it's not a great thing to tell noobies to do because they will get burned. So don't tell them. As they advance they'll naturally learn about this feature. And hopefully they have learned the implications by the time they learn how to do this.
(not me): https://www.seancassidy.me/dont-pipe-to-your-shell.html