4 ms·

What's the problem here? The script is served over https, so it's not going to be tanpwred with (unless you have a malicious cert, but at that point you can't

What's the problem here? The script is served over https, so it's not going to be tanpwred with (unless you have a malicious cert, but at that point you can't trust anyone), and curl | bash isn't any worse than downloading a script and just running it, or running a precompiled binary you don't trust.

Cthulhu_ 5y ago
The request itself won't be tampered with, but what if the host was? That endpoint could be compromised and send you a different script. They should offer a download with signature validation instead. Signed by Apple, Microsoft, etc if possible.
- maccard 5y ago
  If you're afraid the host may be untrusted then you would be wrong to download any of their code at all. The safety is in reviewing the code there, not in avoiding curl | bash. Running pip install or npm install is just as dangerous. > They should offer a download with signature validation instead. Signed by Apple, Microsoft, etc if possible. If the host is compromised, the attacker will just get Microsoft to sign their malware instead; see [0]. If the host is compromised, and you run the code without reviwing it, you're hosed regardless. [0] https://arstechnica.com/gadgets/2021/06/microsoft-digitally-signs-malicious-rootkit-driver/ https://arstechnica.com/gadgets/2021/06/microsoft-digitally-...
- dragonwriter 5y ago
  > The request itself won't be tampered with, but what if the host was? What if your distro package repository was?
doix 5y ago
pyenv could get taken over and you won't know. It's also possible to detect when someone is piping to bash (on the server) and serve a different payload [0]. You're better off piping curl to a file, reviewing the file and then running it manually. [0]: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...
- nerdponx 5y ago
  You often want to do this anyway, because the installer often supports various options and env vars. If you download the file you can read its --help output, and even keep it on hand in case something bad happens, or just for your own records.
- maccard 5y ago
  > its also possible to detect when someone is piping to bash (on the server) and serve a different payload. If you have a fear of your source maliciously serving you different code over curl, don't run their code at all. > You're better off piping curl to a file, reviewing the file and then running it manually. Right, but the safety there is reviewing the code. Running brew install, npm install, pip install, or a binary could all run malicious code too.
- KronisLV 5y ago
  Shouldn't there be some CLI tool that would allow verifying the checksum of the file as an intermediate step? Something along the lines of: curl https://pyenv.run | pass_on_through_sdtout_if_hash_matches md5 8bffaf30c9ba21393329d531063056fe | bash That way, someone who validates the file locally, can be sure that what's piped is the same thing.
  - maccard 5y ago
    Yes, there absolutely should be. It would be a massive improvement if that happened. It requires a few extra steps to be actually secure. You actually need to verify the hash from a trusted source for it to be actually secure. If the delivery has been tampered with, you need to ensure that the delivery of the hash has also not been tampered with. In practice, codesigning is the solution, but certs are expensive, and impractical for a small project.
    - KronisLV 5y ago
      How about the hash being something that you calculate locally? 1. (local) Download the file from the URL. 2. (local) Review it locally, in a text editor. 3. (local) Get its hash locally, from the file in your file system. 4. (SSH) Feed this hash into the fictional tool above. 5. (SSH) If what curl gets is the same as the file that you've reviewed, it gets piped further into bash, otherwise the execution stops and an error is output. Of course, that's only applicable to this particular case, where a compromised server could detect that a bash pipe is used and return different file contents. That would only be useful in situations where you want to review it on a local device, such as a desktop and run it on a remote one, such as a server. Edit: If you want to review it remotely, there's nothing to prevent you from using less or something to view it before manually opening it with Bash. That just requires the discipline to not use one liners that both download and run it, as long as no such tool like the above exisdts.
jayknight 5y ago
It's also possible for you to copy things you can't see from web pages. So the command(s) you end up with may not be what you thought. So there's a trust issue with the site you get instructions from ass well. See http://thejh.net/misc/website-terminal-copy-paste http://thejh.net/misc/website-terminal-copy-paste

Cthulhu_ 5y ago

The request itself won't be tampered with, but what if the host was? That endpoint could be compromised and send you a different script. They should offer a download with signature validation instead. Signed by Apple, Microsoft, etc if possible.

maccard 5y ago
If you're afraid the host may be untrusted then you would be wrong to download any of their code at all. The safety is in reviewing the code there, not in avoiding curl | bash. Running pip install or npm install is just as dangerous. > They should offer a download with signature validation instead. Signed by Apple, Microsoft, etc if possible. If the host is compromised, the attacker will just get Microsoft to sign their malware instead; see [0]. If the host is compromised, and you run the code without reviwing it, you're hosed regardless. [0] https://arstechnica.com/gadgets/2021/06/microsoft-digitally-signs-malicious-rootkit-driver/ https://arstechnica.com/gadgets/2021/06/microsoft-digitally-...
dragonwriter 5y ago
> The request itself won't be tampered with, but what if the host was? What if your distro package repository was?

doix 5y ago

pyenv could get taken over and you won't know. It's also possible to detect when someone is piping to bash (on the server) and serve a different payload [0]. You're better off piping curl to a file, reviewing the file and then running it manually. [0]: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

nerdponx 5y ago
You often want to do this anyway, because the installer often supports various options and env vars. If you download the file you can read its --help output, and even keep it on hand in case something bad happens, or just for your own records.
maccard 5y ago
> its also possible to detect when someone is piping to bash (on the server) and serve a different payload. If you have a fear of your source maliciously serving you different code over curl, don't run their code at all. > You're better off piping curl to a file, reviewing the file and then running it manually. Right, but the safety there is reviewing the code. Running brew install, npm install, pip install, or a binary could all run malicious code too.
KronisLV 5y ago
Shouldn't there be some CLI tool that would allow verifying the checksum of the file as an intermediate step? Something along the lines of: curl https://pyenv.run | pass_on_through_sdtout_if_hash_matches md5 8bffaf30c9ba21393329d531063056fe | bash That way, someone who validates the file locally, can be sure that what's piped is the same thing.
- maccard 5y ago
  Yes, there absolutely should be. It would be a massive improvement if that happened. It requires a few extra steps to be actually secure. You actually need to verify the hash from a trusted source for it to be actually secure. If the delivery has been tampered with, you need to ensure that the delivery of the hash has also not been tampered with. In practice, codesigning is the solution, but certs are expensive, and impractical for a small project.
  - KronisLV 5y ago
    How about the hash being something that you calculate locally? 1. (local) Download the file from the URL. 2. (local) Review it locally, in a text editor. 3. (local) Get its hash locally, from the file in your file system. 4. (SSH) Feed this hash into the fictional tool above. 5. (SSH) If what curl gets is the same as the file that you've reviewed, it gets piped further into bash, otherwise the execution stops and an error is output. Of course, that's only applicable to this particular case, where a compromised server could detect that a bash pipe is used and return different file contents. That would only be useful in situations where you want to review it on a local device, such as a desktop and run it on a remote one, such as a server. Edit: If you want to review it remotely, there's nothing to prevent you from using less or something to view it before manually opening it with Bash. That just requires the discipline to not use one liners that both download and run it, as long as no such tool like the above exisdts.

jayknight 5y ago

It's also possible for you to copy things you can't see from web pages. So the command(s) you end up with may not be what you thought. So there's a trust issue with the site you get instructions from ass well. See http://thejh.net/misc/website-terminal-copy-paste http://thejh.net/misc/website-terminal-copy-paste