5 ms·

Um, no. Curl-to-shell is bad. Check this out: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ https://www.idontplaydarts.com/2016/

Um, no. Curl-to-shell is bad. Check this out: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

aequitas 7y ago
As the author notes: > You’re not running some random shell script from a random author, you’re running it from a software vendor who you already trust to run software.
- falcolas 7y ago
  Without any form of validation that the shell script I'm running is actually from the software vendor in question. That trust is even further stretched when the request is 301 redirected to another host entirely. Between custom domain names, TLDs, Let's Encrypt (I love Let's Encrypt, but it provides is encryption, not trust) and cheeky developers using combinations of those, how can I really know that a script coming from (fictional example) https://install.dock.er https://install.dock.er is actually the Docker company?
  - aequitas 7y ago
    The same arguments apply for downloading a binary. If you want to pull this even further. When is the last time you verified the signing keys of your OS distribution repo without relying on the internet? A lot of install methods that are not curl/sh are like: here copy this bash line to add apt GPG keys for our repo, apt update and install. A lot of people don't bother to check those keys.
    - falcolas 7y ago
      True, some people don't check those keys, but it's possible to do. There's a well trodden (and cryptographically secure) path for gaining trust in a key that's distinct from downloading and unpackaging a file. This is (currently) not possible to do with scripts downloaded from a web page. Especially when immediately piped into a shell.
      - aequitas 7y ago
        As with most issues in security its a balance between usability and security. The real problem is the majority of the users will always try to find the path of least resistance. No matter how well documented a secure procedure is, if a user can find a oneliner they will use it instead. I've seen this in other places as well. Vendor makes a comprehensive guide. Some people condense that to a minimum and will even boast they "made" an easier way to do X or Z, whilst ommiting all the caveats. Of course that will become the popular 'standard' people find. And they'll go complain to the vendor if it doesn't work without even reading the original instructions.
        falcolas 7y ago
        You're not wrong with your first paragraph. That doesn't make the use of curl|sh good however. It doesn't justify developers laziness in eschewing secure methods of distribution, or writing articles like this that justify that same laziness.
- eeZah7Ux 7y ago
  Wrong. You are trusting much more than that, including network components outside of your control and the author's. Plus you are pushing forward the bad pattern and being part of the problem. You are encouraging other authors and users to do the same.
  - aequitas 7y ago
    Tell me how this is different for downloading a binary instead. Unless you get something like a GPG through a completely different channel.
    - eeZah7Ux 7y ago
      First, distribution do exactly that. The GPG chain of trust is preinstalled. Second, there are at least 3-4 more attacks possible during curl-bash. You can simply read the links on HN.
sagichmal 7y ago
A major point of the article is that there's nothing unique about curl-to-shell which enables this exploit; it would be equally easy to perform it with a fully-signed and checksummed binary downloaded through a secure channel.
- htns 7y ago
  You do need to control both the key and the channel in this case.
- hoophoop 7y ago
  That major point is plain wrong. https://sysdig.com/blog/friends-dont-let-friends-curl-bash/ https://sysdig.com/blog/friends-dont-let-friends-curl-bash/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b... These attacks can be mounted on the network side. Also you can inadvertently execute data from a benign captive portal or a server error page and so on.
  - jdefr89 7y ago
    I can do similar attacks on ANYTHING in the form of grabbing code and running it on my machine.. If you aren't doing 'curl | bash' recklessly it isn't a problem.
jchw 7y ago
If you don’t actually read or verify the script this doesn’t matter. If you cant trust the server you probably shouldn’t run any code from it.
- hoophoop 7y ago
  But you can trust the large userbase of a popular Linux distribuiton, especially when big companies use it.
  - jchw 7y ago
    Distro package managers have other advantages than trust. Typically they at least verify cryptographic hashes but many of them also verify public key signatures as well. This is why its safe to download packages from mirrors. With that having been said, Debian takes an extra step into the absurd by using plain HTTP with no TLS for downloading packages. There’s no obvious security issue with that, but it does feel like a bad decision, since anyone in your request path can see what software you’re installing, and if there ever were a vulnerability it would be much easier to exploit due to the lack of security at the transport layer.
- falcolas 7y ago
  How does one trust a server? What assurances can any server provide that they are who they say they are? x509 certificates certainly don't provide those assurances.
  - jchw 7y ago
    No no no, human trust, not machine/cryptographic trust. The same way you have human trust (or distrust) over many things running on your computer. You didn’t get to verify any of the code in the firmware either. There’s differing levels of paranoia. I don’t pipe curl to shell at work. I do it at home sometimes, usually via Github.
jdefr89 7y ago
Did you not read the article? He addresses those points for the most part. The primary idea is that when you run ANY SOFTWARE in reality you have no clue what it might do, you didn't look through every single line of code. There is nothing wrong with 'curl .. | sh' as long as you're running a script completely blind.
- falcolas 7y ago
  "Compared to running with razor blades, running with scissors is fine," is not much of a justification of an activity. Instead of providing justifications, perhaps we should focus on education (or making it simpler to be secure)?

Um, no. Curl-to-shell is bad. Check this out: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

aequitas 7y ago

As the author notes: > You’re not running some random shell script from a random author, you’re running it from a software vendor who you already trust to run software.

falcolas 7y ago
Without any form of validation that the shell script I'm running is actually from the software vendor in question. That trust is even further stretched when the request is 301 redirected to another host entirely. Between custom domain names, TLDs, Let's Encrypt (I love Let's Encrypt, but it provides is encryption, not trust) and cheeky developers using combinations of those, how can I really know that a script coming from (fictional example) https://install.dock.er https://install.dock.er is actually the Docker company?
- aequitas 7y ago
  The same arguments apply for downloading a binary. If you want to pull this even further. When is the last time you verified the signing keys of your OS distribution repo without relying on the internet? A lot of install methods that are not curl/sh are like: here copy this bash line to add apt GPG keys for our repo, apt update and install. A lot of people don't bother to check those keys.
  - falcolas 7y ago
    True, some people don't check those keys, but it's possible to do. There's a well trodden (and cryptographically secure) path for gaining trust in a key that's distinct from downloading and unpackaging a file. This is (currently) not possible to do with scripts downloaded from a web page. Especially when immediately piped into a shell.
    - aequitas 7y ago
      As with most issues in security its a balance between usability and security. The real problem is the majority of the users will always try to find the path of least resistance. No matter how well documented a secure procedure is, if a user can find a oneliner they will use it instead. I've seen this in other places as well. Vendor makes a comprehensive guide. Some people condense that to a minimum and will even boast they "made" an easier way to do X or Z, whilst ommiting all the caveats. Of course that will become the popular 'standard' people find. And they'll go complain to the vendor if it doesn't work without even reading the original instructions.
      - falcolas 7y ago
        You're not wrong with your first paragraph. That doesn't make the use of curl|sh good however. It doesn't justify developers laziness in eschewing secure methods of distribution, or writing articles like this that justify that same laziness.
eeZah7Ux 7y ago
Wrong. You are trusting much more than that, including network components outside of your control and the author's. Plus you are pushing forward the bad pattern and being part of the problem. You are encouraging other authors and users to do the same.
- aequitas 7y ago
  Tell me how this is different for downloading a binary instead. Unless you get something like a GPG through a completely different channel.
  - eeZah7Ux 7y ago
    First, distribution do exactly that. The GPG chain of trust is preinstalled. Second, there are at least 3-4 more attacks possible during curl-bash. You can simply read the links on HN.

sagichmal 7y ago

A major point of the article is that there's nothing unique about curl-to-shell which enables this exploit; it would be equally easy to perform it with a fully-signed and checksummed binary downloaded through a secure channel.

htns 7y ago
You do need to control both the key and the channel in this case.
hoophoop 7y ago
That major point is plain wrong. https://sysdig.com/blog/friends-dont-let-friends-curl-bash/ https://sysdig.com/blog/friends-dont-let-friends-curl-bash/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b... These attacks can be mounted on the network side. Also you can inadvertently execute data from a benign captive portal or a server error page and so on.
- jdefr89 7y ago
  I can do similar attacks on ANYTHING in the form of grabbing code and running it on my machine.. If you aren't doing 'curl | bash' recklessly it isn't a problem.

jchw 7y ago

If you don’t actually read or verify the script this doesn’t matter. If you cant trust the server you probably shouldn’t run any code from it.

hoophoop 7y ago
But you can trust the large userbase of a popular Linux distribuiton, especially when big companies use it.
- jchw 7y ago
  Distro package managers have other advantages than trust. Typically they at least verify cryptographic hashes but many of them also verify public key signatures as well. This is why its safe to download packages from mirrors. With that having been said, Debian takes an extra step into the absurd by using plain HTTP with no TLS for downloading packages. There’s no obvious security issue with that, but it does feel like a bad decision, since anyone in your request path can see what software you’re installing, and if there ever were a vulnerability it would be much easier to exploit due to the lack of security at the transport layer.
falcolas 7y ago
How does one trust a server? What assurances can any server provide that they are who they say they are? x509 certificates certainly don't provide those assurances.
- jchw 7y ago
  No no no, human trust, not machine/cryptographic trust. The same way you have human trust (or distrust) over many things running on your computer. You didn’t get to verify any of the code in the firmware either. There’s differing levels of paranoia. I don’t pipe curl to shell at work. I do it at home sometimes, usually via Github.

jdefr89 7y ago

Did you not read the article? He addresses those points for the most part. The primary idea is that when you run ANY SOFTWARE in reality you have no clue what it might do, you didn't look through every single line of code. There is nothing wrong with 'curl .. | sh' as long as you're running a script completely blind.

falcolas 7y ago
"Compared to running with razor blades, running with scissors is fine," is not much of a justification of an activity. Instead of providing justifications, perhaps we should focus on education (or making it simpler to be secure)?