4 ms·

This page is completely wrong. `curl | sh` is insecure if you're using an http url, although as has already been said here, it's not really any more insecure t

by eridius 10y ago

This page is completely wrong. `curl | sh` is insecure if you're using an http url, although as has already been said here, it's not really any more insecure than "download this script and run it", unless you're expecting all of your users to actually read through the whole script first. But if you're using an https url then you should be ok since the page cannot be hijacked or modified en route (unless the attacker actually has a trusted certificate for the domain, which is an attack that's way out of scope of this discussion). The biggest risk with this approach, which the page doesn't even mention, is the danger of the connection being terminated before the whole script is downloaded, as the shell will still evaluate what was sent. But this can be handled in the script by making sure that an early EOF means nothing is actually run (e.g. you can wrap the whole script in a bash function, and then the last line executes the function). So if you're using an https url, and the script is written to be resilient against early termination, then this is a perfectly reasonable way to install things.

nodesocket 10y ago
Perfect answer. Wrapping the entire script in a function is a clever idea to protect against connection drops as well.
fabrice_d 10y ago
That is true, but that doesn't protect you from the server being hacked and the script replaced by a malicious one. If you execute unsigned code from a 3rd party without sandboxing, transport encrytion doesn't help you much.
matt4711 10y ago
There was a post on HN a while ago where somebody wrote a server side tool which can detect curl -> bash piping and delivered different content if that happens.
- arcticfox 10y ago
  Sure, but how is that any less secure than other installation alternatives? As the site owner, I could swap out a valid package for a troll package at any moment to any subset of users I wanted to if they're not validating the contents of it...
  - dredmorbius 10y ago
    You can't change the contents on a user's local storage that they've verified. Curlbash lets you change out offerings at will, and leaves no auditable source for the user.
laurentdc 10y ago
The website could be compromised though, and you'd have no reliable checksum to compare against (unlike a proper repository). Similarly to what happened to e.g. https://transmissionbt.com/keydnap_qa/ https://transmissionbt.com/keydnap_qa/ or http://www.classicshell.net/forum/viewtopic.php?t=6441 http://www.classicshell.net/forum/viewtopic.php?t=6441
- eridius 10y ago
  This is not a risk inherent to `curl | sh`, it's a risk that you run any time you download software from anywhere that doesn't have a signature using a key that you've already previously verified as trustworthy.
  - falcolas 10y ago
    Which is why most package managers for installling software use signatures. .msi, .deb, .app, .rpm... all provide methods for signing code, and can refuse to install code without signatures or improper signatures.
    - eridius 10y ago
      `curl | sh` isn't used as an alternative to package managers, it's used as an alternative to "download this script and run it".
      - jjnoakes 10y ago
        Not sure why you are being downvoted, you are completely correct.
      - falcolas 10y ago
        `curl | sh` is not an alternative; it is exactly download this script and run it. The problem is "to what end". Most of the time, the script being run is installing software. Be it Docker, Prometheus, homebrew, or otherwise, the entire purpose of most of these scripts is to install software. So, why not just install using a package manager that takes some actual security precautions? The answer is, most of the time, that software developers are either "moving too fast" (docker is guilty of this, but at least they are using the underlying package manager) or more often are just too lazy to provide packages through authenticated channels.
btgeekboy 10y ago
There's a few subtle differences you haven't mentioned: 1) If you attempt to read the script in your browser first, and everything's great, then go pipe to bash, the server can send alternate content based on your user agent. 2) You'd have a hard time proving the first point, or reviewing to see if a script acted poorly, if you didn't have a local copy, which piping to a shell like this normally prevents you from doing.
- chrismonsanto 10y ago
  > If you attempt to read the script in your browser first, and everything's great, then go pipe to bash, the server can send alternate content based on your user agent. If you can't trust the site to give you a safe installer then you can't trust the rest of the sources it gives you either--you would need to audit the entire package. Virtually nobody is going to do that. Singling out the installer as uniquely dangerous is security theater.
  - seanp2k2 10y ago
    Windows and OSX also do this and present pointless non-defeatable "omg but this is from the scary internet, are you SURE you want to run it????"
    - thedudemabry 10y ago
      To be fair, those have been very effective in keeping my non-techie family members from accidentally installing malware because they'll at least check with me when presented with a scary system dialog. And it hasn't impacted my own use other than the occasional extra clicks. In a locked-down corporate setting, I can see how that could be maddening, though.
    - inimino 10y ago
      That's for the benefit of people who don't really realize that installing software from the internet is dangerous (i.e. most users). This discussion is about safe methods once you have decided to install something from the internet, which is different.
falcolas 10y ago
> if you're using an https url then you should be ok You're trusting the server in this case, not the contents being provided by the server. There's no way to verify that the contents attributed to eridius on github are the same contents that eridius actually put up there. Github in particular has been shown to have problems with spoofed users. Let's go one step further. I have a `curl | sh` script for you to execute to install Docker. Just run: curl -fsSL https://get.docker.com/ | sh Oops. That was actually get.rekcod.com, with a RTL unicode character embedded. Or a unicode C which doesn't map to the ascii 'c'. Or I am able to mitm and strip the TLS. Or... The vulnerabilities go on and on. Using only HTTPS, you have no way to prove that the code you got from get.docker.com is the code that the docker engineers intended for you to use.

by eridius 10y ago

nodesocket 10y ago

Perfect answer. Wrapping the entire script in a function is a clever idea to protect against connection drops as well.

fabrice_d 10y ago

That is true, but that doesn't protect you from the server being hacked and the script replaced by a malicious one. If you execute unsigned code from a 3rd party without sandboxing, transport encrytion doesn't help you much.

matt4711 10y ago

There was a post on HN a while ago where somebody wrote a server side tool which can detect curl -> bash piping and delivered different content if that happens.

arcticfox 10y ago
Sure, but how is that any less secure than other installation alternatives? As the site owner, I could swap out a valid package for a troll package at any moment to any subset of users I wanted to if they're not validating the contents of it...
- dredmorbius 10y ago
  You can't change the contents on a user's local storage that they've verified. Curlbash lets you change out offerings at will, and leaves no auditable source for the user.

laurentdc 10y ago

The website could be compromised though, and you'd have no reliable checksum to compare against (unlike a proper repository). Similarly to what happened to e.g. https://transmissionbt.com/keydnap_qa/ https://transmissionbt.com/keydnap_qa/ or http://www.classicshell.net/forum/viewtopic.php?t=6441 http://www.classicshell.net/forum/viewtopic.php?t=6441

eridius 10y ago
This is not a risk inherent to `curl | sh`, it's a risk that you run any time you download software from anywhere that doesn't have a signature using a key that you've already previously verified as trustworthy.
- falcolas 10y ago
  Which is why most package managers for installling software use signatures. .msi, .deb, .app, .rpm... all provide methods for signing code, and can refuse to install code without signatures or improper signatures.
  - eridius 10y ago
    `curl | sh` isn't used as an alternative to package managers, it's used as an alternative to "download this script and run it".
    - jjnoakes 10y ago
      Not sure why you are being downvoted, you are completely correct.
    - falcolas 10y ago
      `curl | sh` is not an alternative; it is exactly download this script and run it. The problem is "to what end". Most of the time, the script being run is installing software. Be it Docker, Prometheus, homebrew, or otherwise, the entire purpose of most of these scripts is to install software. So, why not just install using a package manager that takes some actual security precautions? The answer is, most of the time, that software developers are either "moving too fast" (docker is guilty of this, but at least they are using the underlying package manager) or more often are just too lazy to provide packages through authenticated channels.

btgeekboy 10y ago

There's a few subtle differences you haven't mentioned: 1) If you attempt to read the script in your browser first, and everything's great, then go pipe to bash, the server can send alternate content based on your user agent. 2) You'd have a hard time proving the first point, or reviewing to see if a script acted poorly, if you didn't have a local copy, which piping to a shell like this normally prevents you from doing.

chrismonsanto 10y ago
> If you attempt to read the script in your browser first, and everything's great, then go pipe to bash, the server can send alternate content based on your user agent. If you can't trust the site to give you a safe installer then you can't trust the rest of the sources it gives you either--you would need to audit the entire package. Virtually nobody is going to do that. Singling out the installer as uniquely dangerous is security theater.
- seanp2k2 10y ago
  Windows and OSX also do this and present pointless non-defeatable "omg but this is from the scary internet, are you SURE you want to run it????"
  - thedudemabry 10y ago
    To be fair, those have been very effective in keeping my non-techie family members from accidentally installing malware because they'll at least check with me when presented with a scary system dialog. And it hasn't impacted my own use other than the occasional extra clicks. In a locked-down corporate setting, I can see how that could be maddening, though.
  - inimino 10y ago
    That's for the benefit of people who don't really realize that installing software from the internet is dangerous (i.e. most users). This discussion is about safe methods once you have decided to install something from the internet, which is different.

falcolas 10y ago

> if you're using an https url then you should be ok You're trusting the server in this case, not the contents being provided by the server. There's no way to verify that the contents attributed to eridius on github are the same contents that eridius actually put up there. Github in particular has been shown to have problems with spoofed users. Let's go one step further. I have a `curl | sh` script for you to execute to install Docker. Just run: curl -fsSL https://get.docker.com/ | sh Oops. That was actually get.rekcod.com, with a RTL unicode character embedded. Or a unicode C which doesn't map to the ascii 'c'. Or I am able to mitm and strip the TLS. Or... The vulnerabilities go on and on. Using only HTTPS, you have no way to prove that the code you got from get.docker.com is the code that the docker engineers intended for you to use.