Remember with this kind of thing you're trusting the remote site with access to your terminal emulator. There have been various security problems with some more advanced terminals and escape sequences in the past[1][2].
Personally I think it's a cute thing and have implemented some similar little easter eggs to this via: curl ip.wtf/moo
This is true of anything that ever renders to your terminal. I'm not sure this class of issue is worth worrying about, generally. Sure, these are neat and scary examples. Have you seen some of the recent GPU driver ACEs? Better not render any graphics!
A generalization of this is "receiving information from third parties can lead to security issues" which is of course true. Untrusted inputs are always untrusted.
Piping curl into bash is one thing, but this is on the level of "are you sure you want to open this file downloaded off the internet?" prompts of yore -- it's not productive.
Completely agree, but also I remember that 'piping curl into bash' was always one of the biggest no-no's. I held onto this for so long, but then realized every time I run 'npm i' arbitrary commands can also run, and now it seems wild that I ever cared about curl | bash on websites that I trust
Coming from a Windows world, I've never worried about the `curl | bash` thing. If I would trust an opaque Windows executable from a site, why would I not trust an equally opaque `curl | bash`?
I've even seen people concerned about installing Homebrew that way. It is probably one of the most confusing concerns regarding `curl | bash` given that the it's a package manager designed to run arbitrary Ruby code and is often pulling down precompiled applications.
Windows executables can be signed, and Homebrew formulae are theoretically reviewed and check a hash when they download binaries. With curl | bash, maybe the download fails partway through, or a hacker has replaced the executable on the server or the URL in the copy/paste instructions with a homograph spoof, or the site serves malware when it detects a curl agent.
Part of the reason is that your connection could be interrupted … and then now what? Hope you like sifting through the script’s entirety and manually checking how much it’s done so far.
No, that's exactly how it works. Why would you write such a thing when you're clearly just guessing?
A shell script is interpreted one line at the time.
Very simple proof:
$ while true; do printf 'date\n' && sleep 5; done | sh
Mon 16 May 2022 07:19:21 AM CEST
Mon 16 May 2022 07:19:26 AM CEST
Mon 16 May 2022 07:19:31 AM CEST
In either case, if the network connection is interrupted, the download is finished. How would sh know it's not the whole script as the author intended it? Remember that in a pipeline the receiving end only sees the pipe, and won't know about the exit status of the process upstream (which may for all we know be zero anyway).
Unironically a good idea. Graphics have always been a mistake - most engineers would agree that if we stuck with very basic output, our software would be in a much better place than today (and more usable, too!)
once you become an engineer you cant unsee it very easily, your user vision is now tainted by a higher understanding of problems, rather than feeling frustrated at {FOO = FAIL} bugs and submitting a complaint comment.
It may be worth evaluating why we need to explore this space through computing in the first place? Pen and paper have never failed us before, nor has actually traveling to the space in question.
generally speaking, computers are faster at performing calculations than humans. this can be beneficial for humans, as if they are able to convert a problem (for example, mapping the densities of functions over a 2D space) into a purely mathematical one, humans are able to save significant time and effort.
i both agree and disagree with this. on one hand, it’s true that having everything run in CLI mode would probably make programs truly cross platform. for example, recently I had to use namebenchmark to find the best DNS for my needs. on the M1 mac, the program cannot be run since it’s 32 bit. but i managed to simply run it in a terminal instead by calling its python script (used version 2.7). now i get to run this app on any platform since python is also cross platform. but the GUI version would not be easily ported to linux, windows, etc.
on the other hand, most users are not like me. they want something they can interact with using a mouse, and they often use keyboard only to enter words, not commands or shortcuts. so GUI has definitely a place in today’s world.
Curl isn't the problem they're describing. The remote can assume you're running it in a terminal (especially since the user agent string indicates you're using curl) and can send malicious escape sequences in the body, which will be interpreted by your terminal emulator in most cases.
This is true of any program that prints output directly from a remote host / untrusted source.
In the event your terminal emulator has a vulnerability or allows you to run arbitrary commands (this is a feature of some emulators), the site can target that functionality for users of that emulator and wreak havoc.
I maintain a lot of ANSI escape related code. These exploits have always been theorized, but I've not once heard about this being exploited in the wild. It's certainly possible. Not very probable. Refer to your threat model, as always.
is there way to “sanitize” the curl output such that escaping is disabled?
another commenter mentioned the threats of graphics, but this seems more concerning, esp. in an elevated shell. maybe pipe curl to a text file and inspect before running?
Don't use a terminal emulator, or yes redirect to a file. But that means you'll need to know what the escapes do, and they look cryptic to the layperson. Also, inspect with an editor that replaces non-printing with some other character (like vim, unlike cat) otherwise it's just as bad as letting curl output.
And even then, this is probably not a threat you need to worry about.
No it isn't, or it's at least not the problematic part. curl is just the messenger, and on outputting things to a terminal you can use escape codes, and other things, to do some funky stuff like changing colors or making text blink.
If the terminal has a bug w.r.t. something it processes one could leverage that, but they'd probably need to know which terminal and maybe even which shell you're using; so maybe don't let curl/wget but also `cat` of a downloaded file output directly to the terminal if it isn't a trusted origin or if it looks/feels shady.
To be fair, `sudo curl | sh` is completely different than `sudo curl`.
In one command you pipe the output to `sh` which will run whatever instruction it receives. In another command you just ask for an output from `curl`, doing so should not cause any side effect than the output action itself.
The terminal (or rather terminal emulation) is a mistake, people should stop glorifying it. It has no inherent value, beyond being able to run historical software that was bound to a terminal. Most of all one should stop confusing the terminal and the shell, which remains an interesting concept.
Hard disagree, it has a lot of value and there's a reason it still exists and lots of tooling is still developed for running in terminals and shells, sometimes as exclusive target.
Problems with untrusted, unknown input from any source affects *all* software that process it, internet browsers, document editors, archive extractors, even just opening a file can do lots of funky stuff depending on the file system.
Yes, and I use terminal emulators too, but I look at it the same way I look at browsers. Sure, there is a lot of useful stuff being made with heavy Javascript dependencies, weird Web frameworks, etc., but this doesn't mean that the technology is good in itself.
a terminal is the bare minimum you get when installing an OS (think Arch). is what gives you the power and speed to shape your workflow exactly the way you want it. running shell inside Emacs is not a bad idea, but you don’t get emacs when you install a new OS. you get a terminal that then lets you install emacs. at that point, you might as will just use the terminal.
I don't get what that has to do with my point. Arch leans into terminal enthusiasm, so it is natural that by default all they offer is a tty to install the distribution. But as most other distributions prove, this is not necessary.
Acme and Emacs give good examples of how a non-terminal shell session can look like. They also make clear how a good CLI application should behave like.
which begs the quotation: is there such a thing as a “firewall” for terminals?
my idea is to limit the terminal’s cpu usage so that any breach does not spread quickly in the system, and maybe limit the terminal’s network access, but leave the shell out of it. idk if the last part is possible.
And to be clear, your question is a good one. It's just that it's raised and not begged. That said, I see and hear this all the time, including by historians of philosophy who are strongly familiar with logical fallacies and their distinctions.
Begging the question isn't usually used like this these days, even if it did originate thus. The English language is used the way English speakers use it; yes, even that is quite circular, because there is no formal academy setting down rules that everyone agrees on. Institutions only teach stylistic choices. We use beg the question in exactly the way you say we shouldn't far more often than not to the point that its history is merely a bit of trivia, at least to most American English speakers; Oxford has yet to catch up, but I can't imagine the English situation is that much different than the American one.
I think that is probably excessive, a terminal is hardly as complex as a web browser.
screen or tmux (or even mosh) can essentially act as a terminal firewall, as they interpret escape sequences and maintain a virtual “screen”. Then you can sandbox their process in docker or similar.
Or if you want web browser style sandboxing maybe just using Xterm.js could work.
Personally I think it's a cute thing and have implemented some similar little easter eggs to this via: curl ip.wtf/moo
[1]: https://blog.mozilla.org/security/2019/10/09/iterm2-critical... [2]: https://packetstormsecurity.com/files/162621/rxvt-2.7.0-rxvt...