8 ms·

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

by dgl 4y ago

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 [1]: https://blog.mozilla.org/security/2019/10/09/iterm2-critical-issue-moss-audit/ https://blog.mozilla.org/security/2019/10/09/iterm2-critical... [2]: https://packetstormsecurity.com/files/162621/rxvt-2.7.0-rxvt-unicode-9.22-Code-Execution.html https://packetstormsecurity.com/files/162621/rxvt-2.7.0-rxvt...

mateo1 4y ago
I'm speechless. I never expected running curl could lead to such a security disaster.
- daptaq 4y ago
  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.
  - dredmorbius 4y ago
    Then where should the shell be run?
    - hprotagonist 4y ago
      on the DOM, of course /s
    - daptaq 4y ago
      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.
  - tlamponi 4y ago
    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.
    - daptaq 4y ago
      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.
      - behnamoh 4y ago
        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.
        daptaq 4y ago
        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.
  - olalonde 4y ago
    I have no idea what that comment means.
    - daptaq 4y ago
      I am saying that terminal emulation is bad?
- nickstinemates 4y ago
  `sudo curl | sh` to deploy my awesome service that definitely isn't a bitcoin miner, promise.
  - nirui 4y ago
    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.
  - deleted 4y ago
    [deleted]
behnamoh 4y ago
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.
- texaslonghorn5 4y ago
  Run it in a container?
  - js4ever 4y ago
    Containers can be escaped...
    - nickstinemates 4y ago
      so can vms, yet most of cloud is run on them
  - progval 4y ago
    Containers do not sanitize what programs send to the terminal emulator
- dgl 4y ago
  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.
- dredmorbius 4y ago
  ObLogicalFallaciesNit: It raises the question. 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-fallacy-1689167https://rationalwiki.org/wiki/Begging_the_question https://www.thoughtco.com/what-is-begging-the-question-falla... https://www.writersdigest.com/write-better-fiction/begging-the-question-how-to-use-it-correctly 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.
xyzzy_plugh 4y ago
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.
- spoils19 4y ago
  > Better not render any graphics! 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!)
  - mmcnl 4y ago
    Engineers are not UX designers, so their opinion on UX has little value imo.
    - sunjester 4y ago
      Engineers can't be users?
      - rolph 4y ago
        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.
      - mmcnl 4y ago
        Sure, but their opinion isn't more valuable just because they happen to be engineers as well.
  - 4y ago
thehappypm 4y ago
Is curl unsafe? This is a pretty basic invocation of curl, no fancy flags needed.
- tlamponi 4y ago
  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.
- junon 4y ago
  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.
  - behnamoh 4y ago
    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?
    - junon 4y ago
      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.
usr1106 4y ago
If you have a vulnerable terminal emulator, yes. Well, the same holds for every web site you visit if you have a vulnerable browser.
- usr1106 4y ago
  Unless there were an escape sequence meaning "execute this". I am not aware such beast would exist.
  - progval 4y ago
    It can happen by accident, eg. https://www.openwall.com/lists/oss-security/2016/11/04/12 https://www.openwall.com/lists/oss-security/2016/11/04/12 Archived version of the linked commit: https://archive.softwareheritage.org/browse/revision/b80bedc7c21ecffe99d8d142930db696eebdd6a5/#swh-revision-changes https://archive.softwareheritage.org/browse/revision/b80bedc... (which removes the feature entirely)

by dgl 4y ago

mateo1 4y ago

I'm speechless. I never expected running curl could lead to such a security disaster.

daptaq 4y ago
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.
- dredmorbius 4y ago
  Then where should the shell be run?
  - hprotagonist 4y ago
    on the DOM, of course /s
  - daptaq 4y ago
    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.
- tlamponi 4y ago
  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.
  - daptaq 4y ago
    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.
    - behnamoh 4y ago
      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.
      - daptaq 4y ago
        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.
- olalonde 4y ago
  I have no idea what that comment means.
  - daptaq 4y ago
    I am saying that terminal emulation is bad?
nickstinemates 4y ago
`sudo curl | sh` to deploy my awesome service that definitely isn't a bitcoin miner, promise.
- nirui 4y ago
  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.
- deleted 4y ago
  [deleted]

behnamoh 4y ago

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.

texaslonghorn5 4y ago
Run it in a container?
- js4ever 4y ago
  Containers can be escaped...
  - nickstinemates 4y ago
    so can vms, yet most of cloud is run on them
- progval 4y ago
  Containers do not sanitize what programs send to the terminal emulator
dgl 4y ago
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.
dredmorbius 4y ago
ObLogicalFallaciesNit: It raises the question. 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-fallacy-1689167https://rationalwiki.org/wiki/Begging_the_question https://www.thoughtco.com/what-is-begging-the-question-falla... https://www.writersdigest.com/write-better-fiction/begging-the-question-how-to-use-it-correctly 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.

xyzzy_plugh 4y ago

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.

spoils19 4y ago
> Better not render any graphics! 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!)
- mmcnl 4y ago
  Engineers are not UX designers, so their opinion on UX has little value imo.
  - sunjester 4y ago
    Engineers can't be users?
    - rolph 4y ago
      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.
    - mmcnl 4y ago
      Sure, but their opinion isn't more valuable just because they happen to be engineers as well.
- 4y ago

thehappypm 4y ago

Is curl unsafe? This is a pretty basic invocation of curl, no fancy flags needed.

tlamponi 4y ago
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.
junon 4y ago
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.
- behnamoh 4y ago
  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?
  - junon 4y ago
    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.

usr1106 4y ago

If you have a vulnerable terminal emulator, yes. Well, the same holds for every web site you visit if you have a vulnerable browser.

usr1106 4y ago
Unless there were an escape sequence meaning "execute this". I am not aware such beast would exist.
- progval 4y ago
  It can happen by accident, eg. https://www.openwall.com/lists/oss-security/2016/11/04/12 https://www.openwall.com/lists/oss-security/2016/11/04/12 Archived version of the linked commit: https://archive.softwareheritage.org/browse/revision/b80bedc7c21ecffe99d8d142930db696eebdd6a5/#swh-revision-changes https://archive.softwareheritage.org/browse/revision/b80bedc... (which removes the feature entirely)