8 ms·

Curl to shell isn’t so bad (2019)

40 points by maple3142 7y ago

h2odragon 7y ago
Download and look before running gives you an opportunity to spot something that's obviously, totally wrong... Not that one always uses that chance but at least you had it. Installer systems that chain these "download and run" scripts (Node RED is the most recent I've used) scare me despite all the valid points TFA makes. "Not invented here / history must be reinvented" seems like philosophical point for some of these systems.
- actionowl 7y ago
  Also, I know what git, configure, and make are supposed to do when invoked. I have no idea what piping a random script to sh is supposed to do without reading it.
  - notacoward 7y ago
    You might be surprised. As the OP mentions, configure scripts could contain literally anything. Ditto makefiles. If you're not reading them, you really have no idea what they might do. It's a little harder to embed something awful in git, but with hooks etc. it's not impossible. So when you do "git clone" and "configure" and "make" you're just as subject to vulnerabilities from file replacement or DNS hijacking, and there are just as many opportunities for something bad to happen as if you had piped curl through bash. This is why checking signatures is the most important part of code distribution. It doesn't solve every problem, but it solves most. At least then you know whose code you're getting, and that they attest to the code's validity (including safety). Maybe they're wrong or maybe they're not as good as you thought they were, but it's still a big improvement.
    - actionowl 7y ago
      If we ignore the potential security issues with either approach for a moment and assume for the sake of argument that neither is more risky than the other I "might be surprised" by the behavior of running `./configure` or `make install` but I will almost always be surprised by the behavior downloading and running a random shell script. I prefer a package over either case, but lacking a package I'd prefer to use something that has some expectations of how it should behave. As a packager I find that software with a Makefile, CMakeLists.txt, or a configure script is likely to be easier to package than something that just provides a shell script. Those might still need to be patched or tweaked but there's an expectation that it's going to try to behave a certain way.
- ComodoHacker 7y ago
  Also gives the same opportunity to your AV software if you happen to have one.
- UI_at_80x24 7y ago
  I agree 100%, all this does is reinforce the errors of the past and trains end users to be dumb. This is NO DIFFERENT then Windows users double-clicking on every email attachment. Every time somebody suggests this, the author needs to get slapped with a trout. Copy/Pasting code to get entered is BAD ENOUGH; nobody learns anything that way AND it is not secure! In a race to the bottom everyone looses.
  - t0astbread 7y ago
    There is a difference between downloading, say, the Docker install script from docker.com and opening a random email attachment and that is that I trust docker.com. If I don't trust docker.com because I think it might deliver malware in the install script or a poorly written install script, then I shouldn't use Docker because why would anything different apply to their main software. If I don't trust docker.com because I fear it might be hijacked then I shouldn't use Docker because who guarantees me that their source code or any derived binaries aren't also hijacked.
    - UI_at_80x24 7y ago
      That trust comes from education and experience. Just like an experienced computer user could launch an email attachment safely if they know what they are doing. My point is telling new users to blindly copy/paste/autorun ALL scripts just to get $thing to work only hurts US (FOSS proponents) and the end user.
crdoconnor 7y ago
Curl to shell is usually indicative of a package manager that could be doing a better job.
- meddlepal 7y ago
  If only there was one standard package manager... dealing with brew/apt/[yum|dnf] and handling multiple yearly vendor releases (Ubuntu and Fedora) gets to be annoying.
  - commandlinefan 7y ago
    Not only that, but I always end up with impossible-to-diagnose phantom errors if I start mixing and matching some installations from package manager and some installations from elsewhere (like curl | sh or ./configure, make, make install). I avoid using package managers as much as possible because they do too much hidden, undoable, inscrutable magic behind the scenes that breaks everything when it’s most inconvenient.
    - mbreese 7y ago
      And here, I go the other way -- I keep to only using package managers as much as possible because at least they have some coherent plan for where installation data should go. Random install scripts can put data anywhere and can easily mess with global or system installed data. If I can't set the installation prefix myself, I don't use the code. (I'm sure this issue has something to do with the popularity of containers)
      - debiandev 7y ago
        ...not to mention that (some) distributions do extensive security and legal compliance reviews...
  - mbreese 7y ago
    And some random shell script installer is going to better than a dedicated package manager at dealing with the differences between N many distributions and M many architectures? Sure, some install scripts will be quite simple, but in that case, why do you need to have the install script in the first place? You'd only need it if the installation procedure was too complicated for an `INSTALL` or `README` document.
dwheeler 7y ago
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.
hyperpape 7y ago
My reaction is that curl is just an aggravating factor. The real problem is shell, or really any custom scripts in any language. Acquiring or building software should happen via well-understood reusable tools. Any time building executes bespoke code, you're reducing the maintainability of a system. Distro package managers are one good solution, but a properly developed language package manager would also ideally not rely on custom scripts. A contributing factor to the event-stream issue was that it was considered acceptable to distribute code minimized by _who_knows_what, rather than by any reproducible process.
- oblio 7y ago
  > Distro package managers are one good solution Distro package managers allow execution of custom scripts at every point of the installation. If you're getting packages from outside the distro repos, you're at risk. Sometimes you're at risk even when you get the packages from the distro repos :-)
  - falcolas 7y ago
    A package is signed with a known key, so you can at least trust that the script being executed is from the developer.
    - barkingcat 7y ago
      What about the distros that modify the package before giving it to you? I'm thinking of Debian's modification of openssl for example. https://www.debian.org/security/2008/dsa-1571 https://www.debian.org/security/2008/dsa-1571 Just because it comes from a distro doesn't mean it's from the developer.
      - falcolas 7y ago
        It's still a trust issue. If I'm running a Debian based distribution, I trust Debian packages, and the content of those packages. It's a chain of trust that can't be provided by web servers and X509 certs.
OskarS 7y ago
I mostly agree that curl to shell isn't terrible, but he misses the big negative security implication: the shell scripts are unsigned. It is almost always far, far easier to hack into somebodies website and replace replace "good shell script" with "evil shell script" (or hack into someones GitHub account and make a commit evilifying a shell script) than it is to both do that and get a hold of the developers private key and sign the script. The signing key is usually far more protected and non-public than the web server is. So no, I'm probably not going to review the entire install script either way, but I'm FAR more comfortable running an install script I found online that has been signed by a developer I trust rather than one that hasn't. Package managers and OS installers handle this for you and freak out if there's any issues. In other words, the question with package managers/installers is "Do I trust this developer?". The question with curl-to-sh is "Do I trust this developer AND do I trust that the website hasn't been compromised".
- falcolas 7y ago
  > "Do I trust this developer AND do I trust that the website hasn't been compromised". You also have to verify that the script is coming encrypted over TLS. It's not mandatory, and there's no warnings if its not. Sure, it's an easy check (barring redirects, which also occur), but how many people who are copy/pasting curl|sh scripts will think to do even that basic validation?
  - acdha 7y ago
    Your mistake is assuming that people only do that for curl|sh — in my experience, the same percentage (high) will manually download and run a program / shell script, add an APT/YUM repository, etc. Once someone decides they need to run something the details aren’t very significant. The problem isn’t curl but the challenge of trusting code. The default needs to be either Apple-style sandboxing (note how you get prompted if a new program tries to access your pictures, contacts, etc.) or something like Docker where the default is private with exceptions for the resources you enable.
    - falcolas 7y ago
40four 7y ago
This gained traction a few month ago. Previous discussion === https://news.ycombinator.com/item?id=21490151 https://news.ycombinator.com/item?id=21490151
- Carpetsmoker 7y ago
  Yeah, not sure this needs to be discussed again since it was just 80 days ago (and I say that as the story's author).
commandlinefan 7y ago
> You can regenerate them from autoconf Not that the autoconf input is readable itself, either, anyway...
geocrasher 7y ago
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.
mbreese 7y ago
From the article: === Partial content: the shell may execute half the script due to a network error. Easily fixable by running in a function: do_work() { : } do_work All of the cited examples already do this. === This is the one argument that I think the author gets wrong. Just because the projects he cited do this correctly doesn't mean that all `curl install.sh | sh` scripts will do this correctly. And this is the main fear that I have. I'm not all that concerned about people publishing malicious installation shell scripts. These things are normally public, so it would be easy for them to get caught. I am concerned about the scripts being either (a) altered in transit or (b) corrupted in transit (which is really the same thing). It seems like there could be some happy medium where there was an install script that had a published signature (SHA1 and/or full cryptographically signed), and a tool that downloaded it, verified the signature, and then called a standard function: `my_install()` (or something).
- t0astbread 7y ago
  Well, altered in transit and corrupted in transit are both covered by HTTPS. (I think error detection is even covered in TCP, hence also HTTP?) If a vendor does deliver software over HTTP, then you should verify the script before executing it via a checksum delivered over some secure channel. (This is also what apt, the Debian package manager, does by default afaik.)
  - falcolas 7y ago
    Not just a checksum, a cryptographic signature, which verifies both the contents, and that the contents are from the owner of the key.
  - mbreese 7y ago
    It's still possible for data to be silently corrupted before it hits the HTTPS server [1]. After dealing with a similar issue that corrupted data silently, but still had valid checksums, I tend to not trust implicit checks. (My example wasn't an HTTPS specific issue, but it in theory could still happen with HTTPS). [1] https://stackoverflow.com/questions/34610581/is-it-necessary-to-verify-checksum-when-data-is-sent-over-https https://stackoverflow.com/questions/34610581/is-it-necessary...
lyxsus 7y ago
I'd like to be proven wrong, but isn't thinking that executing unsigned script (bash, js, …) on your computer is somehow inherently less secure than running some binary is nothing but a superstition?
henvic 7y ago
It's not that curl isn't so bad, but that the lack of notarization is really bad. Distributing software safely is still a pain. Linux distributions have this kinda figured out a long time ago with signed packages - almost a requirement if you want to distribute your software on mirrors that you don't control. This is why it's safe to download a package from a Debian HTTP mirror and install it. The thing afaik any of them still don't do, and is really important too, is checking the signature with a revocation policy. I actually started writing about how I distributed a CLI for macOS, Linux, and Windows a few years ago but never finished it. If you are writing Go code you want to take a look at Equinox. I used it to distribute a CLI in my previous job, and it worked like a charm. One of the things I liked most was that I was finally able to push safe updates because I authenticated every release with my private key, and only allowed users to update if the key matched. If you have a primary and a secondary key, and a strategy to revoke it, this means you have a quite safe release process. Related: https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Introduction/Introduction.html https://developer.apple.com/library/archive/documentation/Se... https://equinox.io https://equinox.io https://developer.apple.com/macos/distribution/ https://developer.apple.com/macos/distribution/ https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution?preferredLanguage=occ https://developer.apple.com/documentation/xcode/notarizing_m... https://blog.jessfraz.com/post/why-open-source-firmware-is-important-for-security/ https://blog.jessfraz.com/post/why-open-source-firmware-is-i... https://docs.microsoft.com/en-us/windows/win32/seccrypto/cryptography-tools https://docs.microsoft.com/en-us/windows/win32/seccrypto/cry... https://docs.microsoft.com/en-us/windows/win32/seccrypto/signtool https://docs.microsoft.com/en-us/windows/win32/seccrypto/sig... https://www.mothersruin.com/software/SuspiciousPackage/ https://www.mothersruin.com/software/SuspiciousPackage/ https://successfulsoftware.net/2012/08/30/how-to-sign-your-mac-os-x-app-for-gatekeeper/ https://successfulsoftware.net/2012/08/30/how-to-sign-your-m... https://arstechnica.com/gadgets/2012/02/developers-gatekeeper-a-concern-but-still-gives-power-users-control/ https://arstechnica.com/gadgets/2012/02/developers-gatekeepe...
severine 7y ago
Classic: Is curl|bash insecure? (Sept 25, 2015 | 163 comments) Link: https://sandstorm.io/news/2015-09-24-is-curl-bash-insecure-pgp-verified-install https://sandstorm.io/news/2015-09-24-is-curl-bash-insecure-p... HN discussion: https://news.ycombinator.com/item?id=10277470 https://news.ycombinator.com/item?id=10277470
komali2 7y ago
> if there is a potential security problem and no one is exploiting it, then is it still a security problem?” Yes, surely? Somebody is probably exploiting it and you just aren't aware, because why wouldn't they have that in their toolbox?
- Carpetsmoker 7y ago
  > Somebody is probably exploiting it and you just aren't aware I tried finding an example, and asked last time this was on HN as well, and thus far I've not found a single example. Absolute security isn't realistic; it's often a trade-off between convenience, cost, etc. I can probably break in to your house by throwing a brick through your window ... should we now all invest in more secure windows? Doesn't strike me as a good trade-off for most people.
specialist 7y ago
I just ddg'd "sandbox shell script" and learned about chroot. First hit: How can I “sandbox” a shell script? https://unix.stackexchange.com/questions/363363/how-can-i-sandbox-a-shell-script#363450 https://unix.stackexchange.com/questions/363363/how-can-i-sa... What would a proper sandbox look like? Every session runs within a Docker image? I don't know anything about this stuff. My intro to the sandboxing and security notions was Java and its Applets. I guess I thought we'd eventually do everything that way.

40 points by maple3142 7y ago

Download and look before running gives you an opportunity to spot something that's obviously, totally wrong... Not that one always uses that chance but at least you had it. Installer systems that chain these "download and run" scripts (Node RED is the most recent I've used) scare me despite all the valid points TFA makes. "Not invented here / history must be reinvented" seems like philosophical point for some of these systems.

actionowl 7y ago
Also, I know what git, configure, and make are supposed to do when invoked. I have no idea what piping a random script to sh is supposed to do without reading it.
- notacoward 7y ago
  You might be surprised. As the OP mentions, configure scripts could contain literally anything. Ditto makefiles. If you're not reading them, you really have no idea what they might do. It's a little harder to embed something awful in git, but with hooks etc. it's not impossible. So when you do "git clone" and "configure" and "make" you're just as subject to vulnerabilities from file replacement or DNS hijacking, and there are just as many opportunities for something bad to happen as if you had piped curl through bash. This is why checking signatures is the most important part of code distribution. It doesn't solve every problem, but it solves most. At least then you know whose code you're getting, and that they attest to the code's validity (including safety). Maybe they're wrong or maybe they're not as good as you thought they were, but it's still a big improvement.
  - actionowl 7y ago
    If we ignore the potential security issues with either approach for a moment and assume for the sake of argument that neither is more risky than the other I "might be surprised" by the behavior of running `./configure` or `make install` but I will almost always be surprised by the behavior downloading and running a random shell script. I prefer a package over either case, but lacking a package I'd prefer to use something that has some expectations of how it should behave. As a packager I find that software with a Makefile, CMakeLists.txt, or a configure script is likely to be easier to package than something that just provides a shell script. Those might still need to be patched or tweaked but there's an expectation that it's going to try to behave a certain way.
ComodoHacker 7y ago
Also gives the same opportunity to your AV software if you happen to have one.
UI_at_80x24 7y ago
I agree 100%, all this does is reinforce the errors of the past and trains end users to be dumb. This is NO DIFFERENT then Windows users double-clicking on every email attachment. Every time somebody suggests this, the author needs to get slapped with a trout. Copy/Pasting code to get entered is BAD ENOUGH; nobody learns anything that way AND it is not secure! In a race to the bottom everyone looses.
- t0astbread 7y ago
  There is a difference between downloading, say, the Docker install script from docker.com and opening a random email attachment and that is that I trust docker.com. If I don't trust docker.com because I think it might deliver malware in the install script or a poorly written install script, then I shouldn't use Docker because why would anything different apply to their main software. If I don't trust docker.com because I fear it might be hijacked then I shouldn't use Docker because who guarantees me that their source code or any derived binaries aren't also hijacked.
  - UI_at_80x24 7y ago
    That trust comes from education and experience. Just like an experienced computer user could launch an email attachment safely if they know what they are doing. My point is telling new users to blindly copy/paste/autorun ALL scripts just to get $thing to work only hurts US (FOSS proponents) and the end user.

crdoconnor 7y ago

Curl to shell is usually indicative of a package manager that could be doing a better job.

meddlepal 7y ago
If only there was one standard package manager... dealing with brew/apt/[yum|dnf] and handling multiple yearly vendor releases (Ubuntu and Fedora) gets to be annoying.
- commandlinefan 7y ago
  Not only that, but I always end up with impossible-to-diagnose phantom errors if I start mixing and matching some installations from package manager and some installations from elsewhere (like curl | sh or ./configure, make, make install). I avoid using package managers as much as possible because they do too much hidden, undoable, inscrutable magic behind the scenes that breaks everything when it’s most inconvenient.
  - mbreese 7y ago
    And here, I go the other way -- I keep to only using package managers as much as possible because at least they have some coherent plan for where installation data should go. Random install scripts can put data anywhere and can easily mess with global or system installed data. If I can't set the installation prefix myself, I don't use the code. (I'm sure this issue has something to do with the popularity of containers)
    - debiandev 7y ago
      ...not to mention that (some) distributions do extensive security and legal compliance reviews...
- mbreese 7y ago
  And some random shell script installer is going to better than a dedicated package manager at dealing with the differences between N many distributions and M many architectures? Sure, some install scripts will be quite simple, but in that case, why do you need to have the install script in the first place? You'd only need it if the installation procedure was too complicated for an `INSTALL` or `README` document.

dwheeler 7y ago

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.

hyperpape 7y ago

My reaction is that curl is just an aggravating factor. The real problem is shell, or really any custom scripts in any language. Acquiring or building software should happen via well-understood reusable tools. Any time building executes bespoke code, you're reducing the maintainability of a system. Distro package managers are one good solution, but a properly developed language package manager would also ideally not rely on custom scripts. A contributing factor to the event-stream issue was that it was considered acceptable to distribute code minimized by _who_knows_what, rather than by any reproducible process.

oblio 7y ago
> Distro package managers are one good solution Distro package managers allow execution of custom scripts at every point of the installation. If you're getting packages from outside the distro repos, you're at risk. Sometimes you're at risk even when you get the packages from the distro repos :-)
- falcolas 7y ago
  A package is signed with a known key, so you can at least trust that the script being executed is from the developer.
  - barkingcat 7y ago
    What about the distros that modify the package before giving it to you? I'm thinking of Debian's modification of openssl for example. https://www.debian.org/security/2008/dsa-1571 https://www.debian.org/security/2008/dsa-1571 Just because it comes from a distro doesn't mean it's from the developer.
    - falcolas 7y ago
      It's still a trust issue. If I'm running a Debian based distribution, I trust Debian packages, and the content of those packages. It's a chain of trust that can't be provided by web servers and X509 certs.

OskarS 7y ago

I mostly agree that curl to shell isn't terrible, but he misses the big negative security implication: the shell scripts are unsigned. It is almost always far, far easier to hack into somebodies website and replace replace "good shell script" with "evil shell script" (or hack into someones GitHub account and make a commit evilifying a shell script) than it is to both do that and get a hold of the developers private key and sign the script. The signing key is usually far more protected and non-public than the web server is. So no, I'm probably not going to review the entire install script either way, but I'm FAR more comfortable running an install script I found online that has been signed by a developer I trust rather than one that hasn't. Package managers and OS installers handle this for you and freak out if there's any issues. In other words, the question with package managers/installers is "Do I trust this developer?". The question with curl-to-sh is "Do I trust this developer AND do I trust that the website hasn't been compromised".

falcolas 7y ago
> "Do I trust this developer AND do I trust that the website hasn't been compromised". You also have to verify that the script is coming encrypted over TLS. It's not mandatory, and there's no warnings if its not. Sure, it's an easy check (barring redirects, which also occur), but how many people who are copy/pasting curl|sh scripts will think to do even that basic validation?
- acdha 7y ago
  Your mistake is assuming that people only do that for curl|sh — in my experience, the same percentage (high) will manually download and run a program / shell script, add an APT/YUM repository, etc. Once someone decides they need to run something the details aren’t very significant. The problem isn’t curl but the challenge of trusting code. The default needs to be either Apple-style sandboxing (note how you get prompted if a new program tries to access your pictures, contacts, etc.) or something like Docker where the default is private with exceptions for the resources you enable.
  - falcolas 7y ago

40four 7y ago

This gained traction a few month ago. Previous discussion === https://news.ycombinator.com/item?id=21490151 https://news.ycombinator.com/item?id=21490151

Carpetsmoker 7y ago
Yeah, not sure this needs to be discussed again since it was just 80 days ago (and I say that as the story's author).

commandlinefan 7y ago

> You can regenerate them from autoconf Not that the autoconf input is readable itself, either, anyway...

geocrasher 7y ago

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.

mbreese 7y ago

From the article: === Partial content: the shell may execute half the script due to a network error. Easily fixable by running in a function: do_work() { : } do_work All of the cited examples already do this. === This is the one argument that I think the author gets wrong. Just because the projects he cited do this correctly doesn't mean that all `curl install.sh | sh` scripts will do this correctly. And this is the main fear that I have. I'm not all that concerned about people publishing malicious installation shell scripts. These things are normally public, so it would be easy for them to get caught. I am concerned about the scripts being either (a) altered in transit or (b) corrupted in transit (which is really the same thing). It seems like there could be some happy medium where there was an install script that had a published signature (SHA1 and/or full cryptographically signed), and a tool that downloaded it, verified the signature, and then called a standard function: `my_install()` (or something).

t0astbread 7y ago
Well, altered in transit and corrupted in transit are both covered by HTTPS. (I think error detection is even covered in TCP, hence also HTTP?) If a vendor does deliver software over HTTP, then you should verify the script before executing it via a checksum delivered over some secure channel. (This is also what apt, the Debian package manager, does by default afaik.)
- falcolas 7y ago
  Not just a checksum, a cryptographic signature, which verifies both the contents, and that the contents are from the owner of the key.
- mbreese 7y ago
  It's still possible for data to be silently corrupted before it hits the HTTPS server [1]. After dealing with a similar issue that corrupted data silently, but still had valid checksums, I tend to not trust implicit checks. (My example wasn't an HTTPS specific issue, but it in theory could still happen with HTTPS). [1] https://stackoverflow.com/questions/34610581/is-it-necessary-to-verify-checksum-when-data-is-sent-over-https https://stackoverflow.com/questions/34610581/is-it-necessary...

lyxsus 7y ago

I'd like to be proven wrong, but isn't thinking that executing unsigned script (bash, js, …) on your computer is somehow inherently less secure than running some binary is nothing but a superstition?

henvic 7y ago

It's not that curl isn't so bad, but that the lack of notarization is really bad. Distributing software safely is still a pain. Linux distributions have this kinda figured out a long time ago with signed packages - almost a requirement if you want to distribute your software on mirrors that you don't control. This is why it's safe to download a package from a Debian HTTP mirror and install it. The thing afaik any of them still don't do, and is really important too, is checking the signature with a revocation policy. I actually started writing about how I distributed a CLI for macOS, Linux, and Windows a few years ago but never finished it. If you are writing Go code you want to take a look at Equinox. I used it to distribute a CLI in my previous job, and it worked like a charm. One of the things I liked most was that I was finally able to push safe updates because I authenticated every release with my private key, and only allowed users to update if the key matched. If you have a primary and a secondary key, and a strategy to revoke it, this means you have a quite safe release process. Related: https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Introduction/Introduction.html https://developer.apple.com/library/archive/documentation/Se... https://equinox.io https://equinox.io https://developer.apple.com/macos/distribution/ https://developer.apple.com/macos/distribution/ https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution?preferredLanguage=occ https://developer.apple.com/documentation/xcode/notarizing_m... https://blog.jessfraz.com/post/why-open-source-firmware-is-important-for-security/ https://blog.jessfraz.com/post/why-open-source-firmware-is-i... https://docs.microsoft.com/en-us/windows/win32/seccrypto/cryptography-tools https://docs.microsoft.com/en-us/windows/win32/seccrypto/cry... https://docs.microsoft.com/en-us/windows/win32/seccrypto/signtool https://docs.microsoft.com/en-us/windows/win32/seccrypto/sig... https://www.mothersruin.com/software/SuspiciousPackage/ https://www.mothersruin.com/software/SuspiciousPackage/ https://successfulsoftware.net/2012/08/30/how-to-sign-your-mac-os-x-app-for-gatekeeper/ https://successfulsoftware.net/2012/08/30/how-to-sign-your-m... https://arstechnica.com/gadgets/2012/02/developers-gatekeeper-a-concern-but-still-gives-power-users-control/ https://arstechnica.com/gadgets/2012/02/developers-gatekeepe...

severine 7y ago

Classic: Is curl|bash insecure? (Sept 25, 2015 | 163 comments) Link: https://sandstorm.io/news/2015-09-24-is-curl-bash-insecure-pgp-verified-install https://sandstorm.io/news/2015-09-24-is-curl-bash-insecure-p... HN discussion: https://news.ycombinator.com/item?id=10277470 https://news.ycombinator.com/item?id=10277470

komali2 7y ago

> if there is a potential security problem and no one is exploiting it, then is it still a security problem?” Yes, surely? Somebody is probably exploiting it and you just aren't aware, because why wouldn't they have that in their toolbox?

Carpetsmoker 7y ago
> Somebody is probably exploiting it and you just aren't aware I tried finding an example, and asked last time this was on HN as well, and thus far I've not found a single example. Absolute security isn't realistic; it's often a trade-off between convenience, cost, etc. I can probably break in to your house by throwing a brick through your window ... should we now all invest in more secure windows? Doesn't strike me as a good trade-off for most people.

specialist 7y ago

I just ddg'd "sandbox shell script" and learned about chroot. First hit: How can I “sandbox” a shell script? https://unix.stackexchange.com/questions/363363/how-can-i-sandbox-a-shell-script#363450 https://unix.stackexchange.com/questions/363363/how-can-i-sa... What would a proper sandbox look like? Every session runs within a Docker image? I don't know anything about this stuff. My intro to the sandboxing and security notions was Java and its Applets. I guess I thought we'd eventually do everything that way.