6 ms·

Stop doing `curl get.whatever.com|bash` ! Seriously. I have nothing against your install script, but getting devs use to that is a terrible idea ! I spent week

by jvehent 14y ago

Stop doing `curl get.whatever.com|bash` ! Seriously. I have nothing against your install script, but getting devs use to that is a terrible idea ! I spent weeks explaining to junior devs to not do that on production servers. I thought it was obvious, but apparently it isn't...

nthitz 14y ago
Excuse the naivety but what's the issue?
- freyrs3 14y ago
  It silently executes arbitrary code from a remote server.
- mvanga 14y ago
  You are asking developers to download a shell script from $random_site and run it immediately without any thoughts whatsoever as to what effects it might have. Getting people used to that is a bad idea.
  - nthitz 14y ago
    Is it so different from running a make install or a install.sh script?
    - varikin 14y ago
      The biggest problem is validating the download prior to installing it. The use make install or install.sh or other similar script, the following should be done: Download package md5 package verify md5 == published md5 of packge extract make install / install.sh / etc With "curl package.github.com" | bash" the validation is missing. I don't mind the curl x | bash for my dev machine or testing/dev vms, but that is not happening on production. And if I need said software on production, I have to find a different way to install.
      - paulgb 14y ago
        If the bad guy has intercepted the DNS, they can just provide the md5 of the bad script, no? Maybe the solution here, assuming you trust the third party, is for them to get a signed SSL cert and provide `curl https://get.whatever.com|bash` https://get.whatever.com|bash`
        mechanical_fish 14y ago
        If the bad guy has intercepted the DNS, they can just provide the md5 of the bad script, no? That's enough extra work, and unreliable enough, that the attacker might not bother. Why work so hard to sabotage the user who checks md5sums when you can just wait for a user that doesn't? Just because thieves can carry lockpicks doesn't mean that you shouldn't bother locking your car: Protection against lazy, opportunistic thieves is still better than nothing. The other advantage of the MD5 plan is that you can download the MD5 from a different site than the script, at a different time and over a different internet connection (or, perhaps, over https). A specific, important version of that use case is: If you're installing the script over and over again in an automated fashion, you can download its MD5 in advance, cache it, and then check it against every future download of the script to verify that the script hasn't changed. When the script gets updated and the MD5 legitimately changes, you audit the diff and then update your copy of the MD5 for the future. Meanwhile, using curl-over-HTTPS seems like it couldn't hurt, but better make sure 'curl' is really checking the cert and aborting on cert mismatch, because tools can be very sloppy about this. Also, you're still trusting the third party site, and once their site gets hacked it's game over… unless you have another canonical source for the MD5 sum. One ultimately realizes why real packaging systems have signed packages, with private keys assigned to developers.
    - tptacek 14y ago
      No. Don't use "curl" to download install scripts from HTTP URLs, or, for that matter, from HTTPS sites you don't trust.
- weaksauce 14y ago
  You are piping the output of an untrusted command into a shell that will execute it. This leaves no way to verify that the code your are running is legit. No md5 verification, no cursory inspection of the script, etc.... There could even be hijacked dns that points to a server that specifically does a bad thing. Maybe not a huge deal for small projects but it's not a great idea in general. Try this to see a proof of concept: $echo "echo test" | bash
- tptacek 14y ago
  You mean besides the fact that this gives remote code execution to anyone who can spoof a DNS record?
  - smokeyj 14y ago
    Wouldn't you have bigger problems at that point?
    - mrkurt 14y ago
      No, you might just be drinking coffee, or at a library, or on Google's public Wifi, etc.
      - smokeyj 14y ago
        Say you try logging into your gmail. Couldn't they spoof the DNS and point you to a "proxy" that skims your credentials?
        mrkurt 14y ago
        HTTPS is an entirely different story, I don't know that people would necessarily like installs like "curl https://my.script.ly https://my.script.ly | sh", but there's at least a mechanism to verify the identity of the source.
- borplk 14y ago
  Remote code execution Suppose in the install scripts there happened to be a line like "rm -rf /" then you'll feed that to bash...
  - lucisferre 14y ago
    iirc that command doesn't work anymore on most *nix boxes. Not that I test this fact very often.
ominous_prime 14y ago
I absolutely hate that this is modus operandi for the homebrew and ruby communities. Who though that this is a good idea?
- petercooper 14y ago
  Anyone who values the user experience over the tiny chance of a security breach. I'm not validating it as a good practice, but that seems to be the main reason and I've not heard of Pow or Homebrew causing any problems in this regard.. yet ;-)
  - StavrosK 14y ago
    Never mind the security aspect, how am I going to uninstall the damn thing or upgrade its components (which other things in my system might use) with a custom installer? There's a reason I don't install things that don't use apt.
    - whimsy 14y ago
      https://github.com/yeoman/yeoman/wiki/Manual-Install https://github.com/yeoman/yeoman/wiki/Manual-Install There is a manual installation process provided on the front page; Yeoman itself appears to be a Node.js module in the node package manager npm.
grannyg00se 14y ago
Isn't that just a suggestion to get up and running quickly (for example on a dev VM)? There's nobody forcing devs to blindly follow the instruction and pipe it directly into bash. You are free to curl -L -o install.sh get.whatever.com if you want to inspect the install script.
- Kudos 14y ago
  > There's nobody forcing devs to blindly follow the instruction and pipe it directly into bash "Nobody's forcing you" is the weakest argument.
  - grannyg00se 14y ago
    Citation? Just kidding. It's not an argument at all. It's a manner of speech. To be more verbose: I can't think of a compelling reason why you would blindly type whatever instructions you see on the screen, into your terminal. Unless you were being forced.
baddox 14y ago
To be fair, if you ever install and execute someone else's software without either reading the code yourself or making an attempt to verify that the source is who you intend (i.e. at least checking MD5), then you're guilty of precisely the same security gaffe.
- ricardobeat 14y ago
  A lot more can be done wrong with a shell script pointing to some 3rd party domain than with an installed app, especially with sandboxing in modern OSes, app stores, and the much higher probability and ease of using `sudo` vs executing an app with higher privileges.
- tptacek 14y ago
  No, that is not precisely the same security gaffe. Github (for instance) is itself not as likely to be compromised as my link to Github is.
  - baddox 14y ago
    How do you access Github, if not through a hyperlink which is equally vulnerable to DNS spoofing?
    - tptacek 14y ago
      Neither SSL nor SSH are straightforwardly susceptible to DNS spoofing.
nsheridan 14y ago
Worse, this script goes on to install homebrew using 'curl -k ...|ruby'. Yeah, no thanks.

by jvehent 14y ago

nthitz 14y ago

Excuse the naivety but what's the issue?

freyrs3 14y ago
It silently executes arbitrary code from a remote server.
mvanga 14y ago
You are asking developers to download a shell script from $random_site and run it immediately without any thoughts whatsoever as to what effects it might have. Getting people used to that is a bad idea.
- nthitz 14y ago
  Is it so different from running a make install or a install.sh script?
  - varikin 14y ago
    The biggest problem is validating the download prior to installing it. The use make install or install.sh or other similar script, the following should be done: Download package md5 package verify md5 == published md5 of packge extract make install / install.sh / etc With "curl package.github.com" | bash" the validation is missing. I don't mind the curl x | bash for my dev machine or testing/dev vms, but that is not happening on production. And if I need said software on production, I have to find a different way to install.
    - paulgb 14y ago
      If the bad guy has intercepted the DNS, they can just provide the md5 of the bad script, no? Maybe the solution here, assuming you trust the third party, is for them to get a signed SSL cert and provide `curl https://get.whatever.com|bash` https://get.whatever.com|bash`
      - mechanical_fish 14y ago
        If the bad guy has intercepted the DNS, they can just provide the md5 of the bad script, no? That's enough extra work, and unreliable enough, that the attacker might not bother. Why work so hard to sabotage the user who checks md5sums when you can just wait for a user that doesn't? Just because thieves can carry lockpicks doesn't mean that you shouldn't bother locking your car: Protection against lazy, opportunistic thieves is still better than nothing. The other advantage of the MD5 plan is that you can download the MD5 from a different site than the script, at a different time and over a different internet connection (or, perhaps, over https). A specific, important version of that use case is: If you're installing the script over and over again in an automated fashion, you can download its MD5 in advance, cache it, and then check it against every future download of the script to verify that the script hasn't changed. When the script gets updated and the MD5 legitimately changes, you audit the diff and then update your copy of the MD5 for the future. Meanwhile, using curl-over-HTTPS seems like it couldn't hurt, but better make sure 'curl' is really checking the cert and aborting on cert mismatch, because tools can be very sloppy about this. Also, you're still trusting the third party site, and once their site gets hacked it's game over… unless you have another canonical source for the MD5 sum. One ultimately realizes why real packaging systems have signed packages, with private keys assigned to developers.
  - tptacek 14y ago
    No. Don't use "curl" to download install scripts from HTTP URLs, or, for that matter, from HTTPS sites you don't trust.
weaksauce 14y ago
You are piping the output of an untrusted command into a shell that will execute it. This leaves no way to verify that the code your are running is legit. No md5 verification, no cursory inspection of the script, etc.... There could even be hijacked dns that points to a server that specifically does a bad thing. Maybe not a huge deal for small projects but it's not a great idea in general. Try this to see a proof of concept: $echo "echo test" | bash
tptacek 14y ago
You mean besides the fact that this gives remote code execution to anyone who can spoof a DNS record?
- smokeyj 14y ago
  Wouldn't you have bigger problems at that point?
  - mrkurt 14y ago
    No, you might just be drinking coffee, or at a library, or on Google's public Wifi, etc.
    - smokeyj 14y ago
      Say you try logging into your gmail. Couldn't they spoof the DNS and point you to a "proxy" that skims your credentials?
      - mrkurt 14y ago
        HTTPS is an entirely different story, I don't know that people would necessarily like installs like "curl https://my.script.ly https://my.script.ly | sh", but there's at least a mechanism to verify the identity of the source.
borplk 14y ago
Remote code execution Suppose in the install scripts there happened to be a line like "rm -rf /" then you'll feed that to bash...
- lucisferre 14y ago
  iirc that command doesn't work anymore on most *nix boxes. Not that I test this fact very often.

ominous_prime 14y ago

I absolutely hate that this is modus operandi for the homebrew and ruby communities. Who though that this is a good idea?

petercooper 14y ago
Anyone who values the user experience over the tiny chance of a security breach. I'm not validating it as a good practice, but that seems to be the main reason and I've not heard of Pow or Homebrew causing any problems in this regard.. yet ;-)
- StavrosK 14y ago
  Never mind the security aspect, how am I going to uninstall the damn thing or upgrade its components (which other things in my system might use) with a custom installer? There's a reason I don't install things that don't use apt.
  - whimsy 14y ago
    https://github.com/yeoman/yeoman/wiki/Manual-Install https://github.com/yeoman/yeoman/wiki/Manual-Install There is a manual installation process provided on the front page; Yeoman itself appears to be a Node.js module in the node package manager npm.

grannyg00se 14y ago

Isn't that just a suggestion to get up and running quickly (for example on a dev VM)? There's nobody forcing devs to blindly follow the instruction and pipe it directly into bash. You are free to curl -L -o install.sh get.whatever.com if you want to inspect the install script.

Kudos 14y ago
> There's nobody forcing devs to blindly follow the instruction and pipe it directly into bash "Nobody's forcing you" is the weakest argument.
- grannyg00se 14y ago
  Citation? Just kidding. It's not an argument at all. It's a manner of speech. To be more verbose: I can't think of a compelling reason why you would blindly type whatever instructions you see on the screen, into your terminal. Unless you were being forced.

baddox 14y ago

To be fair, if you ever install and execute someone else's software without either reading the code yourself or making an attempt to verify that the source is who you intend (i.e. at least checking MD5), then you're guilty of precisely the same security gaffe.

ricardobeat 14y ago
A lot more can be done wrong with a shell script pointing to some 3rd party domain than with an installed app, especially with sandboxing in modern OSes, app stores, and the much higher probability and ease of using `sudo` vs executing an app with higher privileges.
tptacek 14y ago
No, that is not precisely the same security gaffe. Github (for instance) is itself not as likely to be compromised as my link to Github is.
- baddox 14y ago
  How do you access Github, if not through a hyperlink which is equally vulnerable to DNS spoofing?
  - tptacek 14y ago
    Neither SSL nor SSH are straightforwardly susceptible to DNS spoofing.

nsheridan 14y ago

Worse, this script goes on to install homebrew using 'curl -k ...|ruby'. Yeah, no thanks.