3 ms·

If you are curl|sh'ing while blindly following some random online to tutorial, it is bad. If you are curl|sh'ing and know why you're curl|sh'ing and know what

If you are curl|sh'ing while blindly following some random online to tutorial, it is bad. If you are curl|sh'ing and know why you're curl|sh'ing and know what you're curl|sh'ing and understand the implications of curl|sh'ing, then I don't see the problem. Like most things, it's subjective.

falcolas 7y ago
How can you know what you're "curl|sh'ing"? If you're piping it, it's impossible to know what you're getting and executing. That's the problem.
- geocrasher 7y ago
  I typically load it up in a web browser, have a peek to make sure it looks sane, and then go for it. If I'm particularly paranoid I can wget it then execute it. But if it's something I'm familiar with, curl|sh is fine. Like I said, it's subjective. No such statement as "curl|sh is bad" or "curl|sh is fine" can be accurate on its own.
  - notabee 7y ago
    Checking in a browser may not be representative. https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...
- geocrasher 7y ago
  And furthermore, it's a matter of trust. If I don't trust the source that I'm running the software from, then curl|sh isn't the problem.
  - falcolas 7y ago
    Trust, and what you download from a web server, are two distinct issues. There is no way to verify that the content you get from a web server is what the developer wrote (particularly when you get into chains of 301 redirects to a github repo. Packages, at least, provide a signature from the developers (or distro packagers) that you can verify independently.
- dmitriid 7y ago
  > If you're piping it, it's impossible to know what you're getting and executing. That's the problem. Exactly the same problem as with apt-get, brew, yum, npm, yarn, cargo, <the list just goes on and on>. Most of those will run any number of scripts during execution without your knowledge.
  - falcolas 7y ago
    I can trust packages, since they're signed by a developer, or by a distribution. I can't trust that the content of a script I obtained via curl is from the developer.
    - dmitriid 7y ago
      npm has had multiple incidents with malicious packages [1][2]. apt had its own CVE [3] [1] https://securityaffairs.co/wordpress/88433/hacking/npm-installer-purescript-compromised.html https://securityaffairs.co/wordpress/88433/hacking/npm-insta... [2] https://securityaffairs.co/wordpress/74497/hacking/malicious-eslint-packages.html https://securityaffairs.co/wordpress/74497/hacking/malicious... [3] https://lists.debian.org/debian-security-announce/2019/msg00010.html https://lists.debian.org/debian-security-announce/2019/msg00...
      - falcolas 7y ago
        NPM packages are not, to the best of my knowledge, cryptographically signed. If you're using them blindly, then you are indeed in the same camp as those who curl|sh. Needless to say, you shouldn't blindly install and run NPM scripts either. And if it takes a CVE to allow a MITM attack to inject a malicious payload into an apt package, that's already better than curl, which does not. It's also worth noting that the CVE had a stable fix available as of that announcement.
        dmitriid 7y ago
        > It's also worth noting that the CVE had a stable fix available as of that announcement. It's also worth noting that the problem was there before it was discovered, fixed, and then disclosed. Ultimately, it comes down to how paranoid you are about your sources of software: https://wiki.c2.com/?TheKenThompsonHack https://wiki.c2.com/?TheKenThompsonHack
- pwinnski 7y ago
  Not impossible at all. If you don't trust the https site from which you're curling, first curl it to a file and check it out. Once you're satisfied, run the curl|sh as documented, or run what your already downloaded.
thinkmassive 7y ago
And sometimes you want a functioning hands-on demo of some open source software that has many moving pieces. If the author has collected a bunch of installation steps into a bash script, I have no problem blindly running it on a fresh isolated VM. Later on if I decide to use the software, the bash script usually makes a nice reference for starting my own Ansible role or Dockerfile.

falcolas 7y ago

How can you know what you're "curl|sh'ing"? If you're piping it, it's impossible to know what you're getting and executing. That's the problem.

geocrasher 7y ago
I typically load it up in a web browser, have a peek to make sure it looks sane, and then go for it. If I'm particularly paranoid I can wget it then execute it. But if it's something I'm familiar with, curl|sh is fine. Like I said, it's subjective. No such statement as "curl|sh is bad" or "curl|sh is fine" can be accurate on its own.
- notabee 7y ago
  Checking in a browser may not be representative. https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...
geocrasher 7y ago
And furthermore, it's a matter of trust. If I don't trust the source that I'm running the software from, then curl|sh isn't the problem.
- falcolas 7y ago
  Trust, and what you download from a web server, are two distinct issues. There is no way to verify that the content you get from a web server is what the developer wrote (particularly when you get into chains of 301 redirects to a github repo. Packages, at least, provide a signature from the developers (or distro packagers) that you can verify independently.
dmitriid 7y ago
> If you're piping it, it's impossible to know what you're getting and executing. That's the problem. Exactly the same problem as with apt-get, brew, yum, npm, yarn, cargo, <the list just goes on and on>. Most of those will run any number of scripts during execution without your knowledge.
- falcolas 7y ago
  I can trust packages, since they're signed by a developer, or by a distribution. I can't trust that the content of a script I obtained via curl is from the developer.
  - dmitriid 7y ago
    npm has had multiple incidents with malicious packages [1][2]. apt had its own CVE [3] [1] https://securityaffairs.co/wordpress/88433/hacking/npm-installer-purescript-compromised.html https://securityaffairs.co/wordpress/88433/hacking/npm-insta... [2] https://securityaffairs.co/wordpress/74497/hacking/malicious-eslint-packages.html https://securityaffairs.co/wordpress/74497/hacking/malicious... [3] https://lists.debian.org/debian-security-announce/2019/msg00010.html https://lists.debian.org/debian-security-announce/2019/msg00...
    - falcolas 7y ago
      NPM packages are not, to the best of my knowledge, cryptographically signed. If you're using them blindly, then you are indeed in the same camp as those who curl|sh. Needless to say, you shouldn't blindly install and run NPM scripts either. And if it takes a CVE to allow a MITM attack to inject a malicious payload into an apt package, that's already better than curl, which does not. It's also worth noting that the CVE had a stable fix available as of that announcement.
      - dmitriid 7y ago
        > It's also worth noting that the CVE had a stable fix available as of that announcement. It's also worth noting that the problem was there before it was discovered, fixed, and then disclosed. Ultimately, it comes down to how paranoid you are about your sources of software: https://wiki.c2.com/?TheKenThompsonHack https://wiki.c2.com/?TheKenThompsonHack
pwinnski 7y ago
Not impossible at all. If you don't trust the https site from which you're curling, first curl it to a file and check it out. Once you're satisfied, run the curl|sh as documented, or run what your already downloaded.

thinkmassive 7y ago

And sometimes you want a functioning hands-on demo of some open source software that has many moving pieces. If the author has collected a bunch of installation steps into a bash script, I have no problem blindly running it on a fresh isolated VM. Later on if I decide to use the software, the bash script usually makes a nice reference for starting my own Ansible role or Dockerfile.