6 ms·

You never want to see raw, attacker-supplied text in a terminal, actually.

Groxx 2y ago
It sure is a good thing we never run anything in our terminals without fully vetting all output. curl -s -L https://raw.githubusercontent.com/Groxx/rickrollrc/master/roll.sh | bash
- labster 2y ago
  You know the rules, and so do I.
  - dv_dt 2y ago
    I know I prefer my exploits to come from opaque corners of package formats or docker layers as bofh intended. The more indirect handoffs of trust the merrier.
    - Timber-6539 2y ago
      Docker is at least sandboxed by default and requires sudo password to run commands.
      - freeone3000 2y ago
        But it requires sudo or effective-sudo to run any command, making such a measure worthless
      - dv_dt 2y ago
        There are advantages to docker, but also disadvantages. Definitely the same w/ "curl | sh" That's all I was trying to allude to, tongue in cheek.
- StableAlkyne 2y ago
  I can't believe curl | sh is still the recommended way to install oh-my-zsh
  - Dylan16807 2y ago
    Getting it out of a repository wouldn't make any more vetting appear as if by magic. And if you're facing an attacker sophisticated enough to send different contents to a browser and to curl, then you're probably not going to find their backdoor in the first place. And it would be stupid of them to depend on that trick, so this becomes an extremely niche case not worth worrying about. And multiply that sophistication by a hundred times because this is on github servers. The "what if the file is truncated" issue is the only realistic one, and competent installers like this one define functions and don't run them until the last line.
    - Repulsion9513 2y ago
      > sophisticated enough to send different contents to a browser and to curl Checking the Accept header (or User-Agent or a bunch of other things) is very difficult :)
      - soraminazuki 2y ago
        GP likely meant differentiating `curl` and `curl | bash`. https://web.archive.org/web/20240520142212/https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ https://web.archive.org/web/20240520142212/https://www.idont...
        Repulsion9513 2y ago
        Did they? IDK, just differentiating browser from curl is incredibly likely to be "good enough" as an attacker.
        Dylan16807 2y ago
        I did have that attack in mind, yes. But honestly it doesn't take a lot of sophistication to hide an exploit somewhere in an entire piece of software. The average person is very vulnerable to a malicious dev and the way they download is very unlikely to matter as long as it's not http:// http://
- Repulsion9513 2y ago
  I mean, the context I was replying to was: > terminals don't have even a small fraction of browsers' malicious-link-defense mechanisms (as demonstrated). I always want to see the full url in a terminal. And yeah you're right if you're just piping stuff to bash, malicious URLs are the least of your worries, but that doesn't change the fact that outputting data (that may contain raw control codes) to your terminal is dangerous with or without linkified-URLs.
lxgr 2y ago
Is that realistic? Sure, text editors and viewers like vim or less can probably filter out terminal escape sequences, but should arbitrary programs printing (potentially user-supplied) strings to stdout have to? Maybe terminal escape sequence processing should be opt-in (on a by-process/job level) rather than opt-out?
- Repulsion9513 2y ago
  `| less`

It sure is a good thing we never run anything in our terminals without fully vetting all output. curl -s -L https://raw.githubusercontent.com/Groxx/rickrollrc/master/roll.sh | bash

labster 2y ago
You know the rules, and so do I.
- dv_dt 2y ago
  I know I prefer my exploits to come from opaque corners of package formats or docker layers as bofh intended. The more indirect handoffs of trust the merrier.
  - Timber-6539 2y ago
    Docker is at least sandboxed by default and requires sudo password to run commands.
    - freeone3000 2y ago
      But it requires sudo or effective-sudo to run any command, making such a measure worthless
    - dv_dt 2y ago
      There are advantages to docker, but also disadvantages. Definitely the same w/ "curl | sh" That's all I was trying to allude to, tongue in cheek.
StableAlkyne 2y ago
I can't believe curl | sh is still the recommended way to install oh-my-zsh
- Dylan16807 2y ago
  Getting it out of a repository wouldn't make any more vetting appear as if by magic. And if you're facing an attacker sophisticated enough to send different contents to a browser and to curl, then you're probably not going to find their backdoor in the first place. And it would be stupid of them to depend on that trick, so this becomes an extremely niche case not worth worrying about. And multiply that sophistication by a hundred times because this is on github servers. The "what if the file is truncated" issue is the only realistic one, and competent installers like this one define functions and don't run them until the last line.
  - Repulsion9513 2y ago
    > sophisticated enough to send different contents to a browser and to curl Checking the Accept header (or User-Agent or a bunch of other things) is very difficult :)
    - soraminazuki 2y ago
      GP likely meant differentiating `curl` and `curl | bash`. https://web.archive.org/web/20240520142212/https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ https://web.archive.org/web/20240520142212/https://www.idont...
      - Repulsion9513 2y ago
        Did they? IDK, just differentiating browser from curl is incredibly likely to be "good enough" as an attacker.
        Dylan16807 2y ago
        I did have that attack in mind, yes. But honestly it doesn't take a lot of sophistication to hide an exploit somewhere in an entire piece of software. The average person is very vulnerable to a malicious dev and the way they download is very unlikely to matter as long as it's not http:// http://
Repulsion9513 2y ago
I mean, the context I was replying to was: > terminals don't have even a small fraction of browsers' malicious-link-defense mechanisms (as demonstrated). I always want to see the full url in a terminal. And yeah you're right if you're just piping stuff to bash, malicious URLs are the least of your worries, but that doesn't change the fact that outputting data (that may contain raw control codes) to your terminal is dangerous with or without linkified-URLs.

lxgr 2y ago

Is that realistic? Sure, text editors and viewers like vim or less can probably filter out terminal escape sequences, but should arbitrary programs printing (potentially user-supplied) strings to stdout have to? Maybe terminal escape sequence processing should be opt-in (on a by-process/job level) rather than opt-out?

Repulsion9513 2y ago
`| less`