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
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!)
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.
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.
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.
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.
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.
It's just cool but practically I never check weather until I'm about to leave home and then I'll just check a local weather app on my phone which should give more accurate and detailed info than a service that covers the entire world with presumably varying degree of accuracy.
but imagine if you're in a bunker hacking on your fav project, no artificial light and you wonder.. shall i go to the surface? you curl this website and, if tolerable weather conditions, you plan your ascent.
I have to scroll all they way down to the buttom to find the information source -- WorldWeatherOnline. Does people not care about where their whether data is sourced from?
Living in Japan, I have always been wary of these type of service, since I find a lot of them really inaccurate. And I just checked, Tokyo show 15C on that website, while high resolution current weather information from Japan Metrological Agency show 18C.
I'll admit I'm just speculating because I don't know much about weather and weather data collection, but is it not possible there's a 3 degree difference between 2 different places of measurement in Tokyo (i.e. both are correct to some degree?)
> while high resolution current weather information from Japan Metrological Agency
They are complaining about location precision. It might be very coarse (equivalent to US zip code size). It’s a valid complaint. I use Dark Sky on iOS because it’s accurate to 10 meters or so.
I agree. I always avoid these aggregators that offer world-wide coverage. The quality of the data is often questionable.
As a cyclist I'm mostly interested in rain. So I check the rain radar of the national weather service, which has excellent resolution.
Even when travelling I spend 5 minutes to dig out the relevant local pages of a national weather service and bookmark them. Not something I have to do so frequently that any kind of automation would be needed.
Weather apps and this client are a solutions in search of a real problem. Yes, it's a nice demo, I like working with the terminal. But I am not working with weather all day long.
This is why I like Windy.com. They give you the output directly from the various weather models and you can actually see them all in parallel or just pick whichever one works best for your location.
Living in the PNW where predicting snowfall can be problematic to say the least, I love looking at the various windy.com models. One particular storm, that lead to about an inch of sticking snow this past winter had ranges from 2-20 inches predicted by the various models. The worst part is the 2 inch prediction came from the model that is generally considered the least reliable for our area.
rate.sx is very good. much better than all of the desktop client trackers out there and the web ones with too much granularity. sometimes i don't want to see the candles i just want to see the price of a particular coin
This is a really nice service and I have used it for quite some time. Just a small reminder; to relieve the wttr servers, please cache the results on disk if you for example want to have a higher refresh rate on your tmux status bar.
See my dotfiles repo [1] if you're interested in such implementation
I'm going to add that if you live in Norway, YR has nice weather data available for free (required by law). Shameless plug for my little CLI tool when I was beginning to learn go:
Readit News
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...
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.
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!)
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.
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.
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.
Begging the question is to answer the question with a premise that assumes the result. It's a form of circular reasoning.
https://www.thoughtco.com/what-is-begging-the-question-falla...
https://www.writersdigest.com/write-better-fiction/begging-t...
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.
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.
Honestly this is a great _simple_ way to access weather without leaving my terminal. Love the basic ASCII graphics.
I noticed it's a LOT faster when I provide the city, probably because it doesn't have to look it up from IP:
``` curl wttr.in/atlanta ```
Nice work.
An example -https://www.onsecurity.io/blog/careless-with-curl-dont-be/ -
Living in Japan, I have always been wary of these type of service, since I find a lot of them really inaccurate. And I just checked, Tokyo show 15C on that website, while high resolution current weather information from Japan Metrological Agency show 18C.
I don't know about Tokyo in particular, but generally speaking, for a large coastal city that wouldn't surprise me at all.
They are complaining about location precision. It might be very coarse (equivalent to US zip code size). It’s a valid complaint. I use Dark Sky on iOS because it’s accurate to 10 meters or so.
As a cyclist I'm mostly interested in rain. So I check the rain radar of the national weather service, which has excellent resolution.
Even when travelling I spend 5 minutes to dig out the relevant local pages of a national weather service and bookmark them. Not something I have to do so frequently that any kind of automation would be needed.
Weather apps and this client are a solutions in search of a real problem. Yes, it's a nice demo, I like working with the terminal. But I am not working with weather all day long.
Weather or not I care is really not your concern.
Also, he maintains the awesome-console-services[5] list
[1] https://github.com/chubin/cheat.sh
[2] https://github.com/chubin/late.nz
[3] https://github.com/chubin/qrenco.de
[4] https://github.com/chubin/rate.sx
[5] https://github.com/chubin/awesome-console-services
I sourced the above commands from a previous HN post: https://news.ycombinator.com/item?id=23646953
See my dotfiles repo [1] if you're interested in such implementation
[1] https://github.com/Granddave/dotfiles/tree/master/tmux
https://github.com/sigg3/weather_query/