9 ms·

$ curl https://install.meteor.com https://install.meteor.com | sh I really wish people would stop giving instructions like this. Despite all the focus on web s

by kisielk 14y ago

$ curl https://install.meteor.com https://install.meteor.com | sh I really wish people would stop giving instructions like this. Despite all the focus on web security and sandboxing, we continue to instruct people to run arbitrary code on their user account. People should at least give any shell script they download from the internet a cursory look to see if it's doing what it should be doing instead of blindly executing the response from an HTTP request.

thisishugo 14y ago
At least it's https; I've seen sites on HN recently[1] that suggest you run code pulled over plain http, as if that wasn't an even more horrible security risk than just blindly running a script from the Internet. [1] http://chocolatey.org/ http://chocolatey.org/
- TazeTSchnitzel 14y ago
  @powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString('http://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%systemdrive%\chocolatey\bin Goodness, that looks awful.
  - orionblastar 14y ago
    Heh the least they could do is put that into a batch file to be downloaded and clicked on to run. Chocolatey is sort of like an alternative apt-get for Windows, except that it doesn't need s sudo command and your password to install software. It uses cinst to install stuff: cinst firefox Installs Firefox. The UAC asks the current user to allow the setup program to run and that is about it. No password needed to install like apt-get has. Oh yeah if your PC doesn't have Powershell installed you are SOL if you try to use that command to install Chocolatey. Some administrators remove it because it can be used to install software without being known to the user.
    - serge2k 14y ago
      Right, because UAC assumes someone who is logged in as an admin is supposed to be. I configure sudo like this on some of my dev machines, easier and I don't care about them (usually just VMs). Why not just restrict the execution policy? I don't really know PS thta well, but doesn't that stop arbitrary (or any) scripts?
      - orionblastar 14y ago
        You are revealing the security flaws of Windows. Cancel or Allow?
bretthoerner 14y ago
I don't understand this argument, unless you include things like gem, pip, npm, etc. `pip install foobar-py` runs a Python setup script, which can do anything bash can. Do you inspect all of those, and comment about their insecurities on HN?
- ohazi 14y ago
  Don't these generally do some sort of cursory signature check?
  - lotyrin 14y ago
    Against a signature they fetched how? Over HTTPS? Just because this style makes you think about it harder, doesn't mean it's less secure. It's the simplest and best case.
- sergiosgc 14y ago
  This method makes you vulnerable to attacks that change the script being run. DNS spoofing, HTTP proxy hacking or hacking of the source server itself. Good package management systems use digital signatures to ensure that the original package wasn't tampered with. Not that hacking of the central repositories never happened, but it's a major (and thus infrequent) event.
  - timdorr 14y ago
    But I know for at least gem and npm, while they support signing, they are not used in practice. And those two repositories are used by a large number of people browsing this site.
bpatrianakos 14y ago
You're right but this is just kind of a nit-pick. It should be up to the user to decide if they trust the source. The way I see it, it all comes down to the question of do you trust the source. If the source is trustworthy from there you've got to worry about an attacker compromising your trusted source. That happens and it sucks but its life and I for one am not going to stop `gem install`ing and `curl`ing because Rubygems.org was compromised once or some other source was tampered with. I know my sources, I trust them. If they're compromised and they take me down with them, I'm going to cry a little but it's not like I'm working on a nuclear reactor - I'm making some shit CRUD app. Now as the importance of a codebase increases the kind of attitude like I have should decrease of course.
- JPKab 14y ago
  "it's not like I'm working on a nuclear reactor - I'm making some shit CRUD app." Finally, some much needed humility on HN. Refreshing. And true.
- alinajaf 14y ago
  > "I'm going to cry a little but it's not like I'm working on a nuclear reactor" Great for you, but you're a developer who presumably works on 'shit CRUD apps' for other people who pay you for the effort. What happens when a script from a compromised source that you run on your devbox grabs the entire contents of ~/.ssh/ and sends it to the bad guys inbox? Congratulations, all your clients have been thoroughly owned.
- hoverkraft 14y ago
  That being said, you'd be amazed at how many ruby gems are required to run the average nuclear reactor.
spullara 14y ago
It would be great if shasum would let you check against a sha on the command line so you could do something like: curl https://install.meteor.com https://install.meteor.com | shasum -c 6fa3128600e9bd73a161a625f8503e6614b44b2b | sh Could be built into curl possibly.
- mayanksinghal 14y ago
  But if the DNS is compromised or if this a MITM attack (in spite of being https) there is no guarantee that the checksum is any more trustworthy.
  - spullara 14y ago
    How is this any less safe than any other checksum scheme that people typically use when delivering software over the internet?
geoffschmidt 14y ago
Meteor dev here.. We actually think this is more secure, or at least does more to raise awareness about security! We want people to BE AWARE that they're running arbitrary code, secured only by the certificate authorities in their local curl install. Just about every other way of installing software ends up letting the remote run arbitrary code on your machine. The disadvantage of the other approaches is that you don't think about it, so you feel safer than you are, and you are more likely to make security-compromising mistakes. - When you download an OS X installer package and run it, it can run arbitrary code during the install. Is that how you installed Postgres or Rails? Hope you downloaded that disk image over http. (The last time you downloaded a disk image, did you check the link to make sure it was https? ... Are you sure you never forget to do that?) - OK, so let's say you download a tarball instead, and untar it into /usr/local, and put meteor in your path. Then the next thing you do is.. you type 'meteor', letting the tarball run arbitrary code. There's not much security difference between letting the remote code run at install time, and letting it run two seconds later when you actually start the program fo the first time. - OK, let's say you downloaded a Meteor tarball, checked its SHA1-- wait, how did you get the correct SHA1? Did you get it off our website? (Best case, over https, bringing us back where we started?) Or did you call me on the phone.. using the phone number you got off of Facebook.. secured by https? (Best case, and only if you manually added https to your Facebook URL. Did you remember to do that?) - No problem, I'll get it out of macports, fink, or homebrew, and hopefully they'll have the correct authoritative hash and validate the download. Well, how do you know you have the real macports? The chain of trust still goes through https and the CA. Arguably this is a little better because presumably many people will notice if the macports download site is hacked, but just as arguably, it's less secure because there's one more potential compromise point (volunteer macport maintainers -- how are they vetted? do they use two factor auth? what if their email account is compromised?) There's really two separate issues here: - Do you trust Meteor enough to run our code? If so, you shouldn't care whether you run curl | sh or whether you download a tarball and unpack it, and then run the program in it. If not, you shouldn't do either. They're equally bad. - Do you trust https and the certificate authorities to protect you from MITM attacks, so that you get the authentic bits from meteor.com and not an imitation? If so, then curl https://foo https://foo solves your problem. If not, you are going to have to find something better than the CA's to serve as your root of trust. Maybe there is an argument for "defense in depth" -- maybe you should fetch the tarball from one server with one CA, and the SHA1 from a second server with a different CA -- sure, in practice that could make a compromise less likely. But that's a bit much to ask of the random OS X user that just wants to come to meteor.com and install the tools. Your best option is clearly to come to the monthly DevShop events at Meteor HQ in SF. If you come to DevShop to install Meteor, I will personally confirm the SHA1 for you :)
timdorr 14y ago
While I agree that there should be some more transparency with the install process, my problem with this is more practical: because I've installed via a non-standard means, how do I uninstall? How do other packages of software know I have meteor installed as a prerequisite? How do I easily ensure I have the latest version? How do I lock my install to a particular version to avoid breaking changes in new versions? Whilst the security aspect is a background concern, these functional concerns are far more important to me. Because npm or some other system wasn't used, meteor is now an outlier and doesn't easily fit into most of my development flow. I've now been burdened with an external maintenance process that requires separate tools and workflow to accommodate. Honestly, that's the biggest turn-off I have about meteor right now. Hopefully that will change before the big 1.0.
patio11 14y ago
This is a security red herring that as far as I can see is justified entirely by an aesthetic preference to think of oneself as "able to quickly audit code just by skimming it." Compare it to alternatives like "gem install NAME_ANY_GEM_HERE", which also executes arbitrary code and which, for the typical Ruby/Rails developer, is totally impenetrable. (If you think otherwise, tell me, when's the last time you did a line-by-line audit of every single dependency prior to installing a gem?) Even the embedded assumptions like e.g. the Rubygems server is, as of this instance, being operated by Rubygems and not being operated by The Adversary are really, really tenuous.
webreac 14y ago
I really like instructions like this because I understand easily what needs to be done. Probably the content of the script will also be easy to read. Of course, I will never do a copy paste of these instructions. I will redirect to a file and read it before executing. And if I have doubts, I launch a VM.

by kisielk 14y ago

thisishugo 14y ago

At least it's https; I've seen sites on HN recently[1] that suggest you run code pulled over plain http, as if that wasn't an even more horrible security risk than just blindly running a script from the Internet. [1] http://chocolatey.org/ http://chocolatey.org/

TazeTSchnitzel 14y ago
@powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString('http://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%systemdrive%\chocolatey\bin Goodness, that looks awful.
- orionblastar 14y ago
  Heh the least they could do is put that into a batch file to be downloaded and clicked on to run. Chocolatey is sort of like an alternative apt-get for Windows, except that it doesn't need s sudo command and your password to install software. It uses cinst to install stuff: cinst firefox Installs Firefox. The UAC asks the current user to allow the setup program to run and that is about it. No password needed to install like apt-get has. Oh yeah if your PC doesn't have Powershell installed you are SOL if you try to use that command to install Chocolatey. Some administrators remove it because it can be used to install software without being known to the user.
  - serge2k 14y ago
    Right, because UAC assumes someone who is logged in as an admin is supposed to be. I configure sudo like this on some of my dev machines, easier and I don't care about them (usually just VMs). Why not just restrict the execution policy? I don't really know PS thta well, but doesn't that stop arbitrary (or any) scripts?
    - orionblastar 14y ago
      You are revealing the security flaws of Windows. Cancel or Allow?

bretthoerner 14y ago

I don't understand this argument, unless you include things like gem, pip, npm, etc. `pip install foobar-py` runs a Python setup script, which can do anything bash can. Do you inspect all of those, and comment about their insecurities on HN?

ohazi 14y ago
Don't these generally do some sort of cursory signature check?
- lotyrin 14y ago
  Against a signature they fetched how? Over HTTPS? Just because this style makes you think about it harder, doesn't mean it's less secure. It's the simplest and best case.
sergiosgc 14y ago
This method makes you vulnerable to attacks that change the script being run. DNS spoofing, HTTP proxy hacking or hacking of the source server itself. Good package management systems use digital signatures to ensure that the original package wasn't tampered with. Not that hacking of the central repositories never happened, but it's a major (and thus infrequent) event.
- timdorr 14y ago
  But I know for at least gem and npm, while they support signing, they are not used in practice. And those two repositories are used by a large number of people browsing this site.

bpatrianakos 14y ago

You're right but this is just kind of a nit-pick. It should be up to the user to decide if they trust the source. The way I see it, it all comes down to the question of do you trust the source. If the source is trustworthy from there you've got to worry about an attacker compromising your trusted source. That happens and it sucks but its life and I for one am not going to stop `gem install`ing and `curl`ing because Rubygems.org was compromised once or some other source was tampered with. I know my sources, I trust them. If they're compromised and they take me down with them, I'm going to cry a little but it's not like I'm working on a nuclear reactor - I'm making some shit CRUD app. Now as the importance of a codebase increases the kind of attitude like I have should decrease of course.

JPKab 14y ago
"it's not like I'm working on a nuclear reactor - I'm making some shit CRUD app." Finally, some much needed humility on HN. Refreshing. And true.
alinajaf 14y ago
> "I'm going to cry a little but it's not like I'm working on a nuclear reactor" Great for you, but you're a developer who presumably works on 'shit CRUD apps' for other people who pay you for the effort. What happens when a script from a compromised source that you run on your devbox grabs the entire contents of ~/.ssh/ and sends it to the bad guys inbox? Congratulations, all your clients have been thoroughly owned.
hoverkraft 14y ago
That being said, you'd be amazed at how many ruby gems are required to run the average nuclear reactor.

spullara 14y ago

It would be great if shasum would let you check against a sha on the command line so you could do something like: curl https://install.meteor.com https://install.meteor.com | shasum -c 6fa3128600e9bd73a161a625f8503e6614b44b2b | sh Could be built into curl possibly.

mayanksinghal 14y ago
But if the DNS is compromised or if this a MITM attack (in spite of being https) there is no guarantee that the checksum is any more trustworthy.
- spullara 14y ago
  How is this any less safe than any other checksum scheme that people typically use when delivering software over the internet?

geoffschmidt 14y ago

Meteor dev here.. We actually think this is more secure, or at least does more to raise awareness about security! We want people to BE AWARE that they're running arbitrary code, secured only by the certificate authorities in their local curl install. Just about every other way of installing software ends up letting the remote run arbitrary code on your machine. The disadvantage of the other approaches is that you don't think about it, so you feel safer than you are, and you are more likely to make security-compromising mistakes. - When you download an OS X installer package and run it, it can run arbitrary code during the install. Is that how you installed Postgres or Rails? Hope you downloaded that disk image over http. (The last time you downloaded a disk image, did you check the link to make sure it was https? ... Are you sure you never forget to do that?) - OK, so let's say you download a tarball instead, and untar it into /usr/local, and put meteor in your path. Then the next thing you do is.. you type 'meteor', letting the tarball run arbitrary code. There's not much security difference between letting the remote code run at install time, and letting it run two seconds later when you actually start the program fo the first time. - OK, let's say you downloaded a Meteor tarball, checked its SHA1-- wait, how did you get the correct SHA1? Did you get it off our website? (Best case, over https, bringing us back where we started?) Or did you call me on the phone.. using the phone number you got off of Facebook.. secured by https? (Best case, and only if you manually added https to your Facebook URL. Did you remember to do that?) - No problem, I'll get it out of macports, fink, or homebrew, and hopefully they'll have the correct authoritative hash and validate the download. Well, how do you know you have the real macports? The chain of trust still goes through https and the CA. Arguably this is a little better because presumably many people will notice if the macports download site is hacked, but just as arguably, it's less secure because there's one more potential compromise point (volunteer macport maintainers -- how are they vetted? do they use two factor auth? what if their email account is compromised?) There's really two separate issues here: - Do you trust Meteor enough to run our code? If so, you shouldn't care whether you run curl | sh or whether you download a tarball and unpack it, and then run the program in it. If not, you shouldn't do either. They're equally bad. - Do you trust https and the certificate authorities to protect you from MITM attacks, so that you get the authentic bits from meteor.com and not an imitation? If so, then curl https://foo https://foo solves your problem. If not, you are going to have to find something better than the CA's to serve as your root of trust. Maybe there is an argument for "defense in depth" -- maybe you should fetch the tarball from one server with one CA, and the SHA1 from a second server with a different CA -- sure, in practice that could make a compromise less likely. But that's a bit much to ask of the random OS X user that just wants to come to meteor.com and install the tools. Your best option is clearly to come to the monthly DevShop events at Meteor HQ in SF. If you come to DevShop to install Meteor, I will personally confirm the SHA1 for you :)

timdorr 14y ago

While I agree that there should be some more transparency with the install process, my problem with this is more practical: because I've installed via a non-standard means, how do I uninstall? How do other packages of software know I have meteor installed as a prerequisite? How do I easily ensure I have the latest version? How do I lock my install to a particular version to avoid breaking changes in new versions? Whilst the security aspect is a background concern, these functional concerns are far more important to me. Because npm or some other system wasn't used, meteor is now an outlier and doesn't easily fit into most of my development flow. I've now been burdened with an external maintenance process that requires separate tools and workflow to accommodate. Honestly, that's the biggest turn-off I have about meteor right now. Hopefully that will change before the big 1.0.

patio11 14y ago

This is a security red herring that as far as I can see is justified entirely by an aesthetic preference to think of oneself as "able to quickly audit code just by skimming it." Compare it to alternatives like "gem install NAME_ANY_GEM_HERE", which also executes arbitrary code and which, for the typical Ruby/Rails developer, is totally impenetrable. (If you think otherwise, tell me, when's the last time you did a line-by-line audit of every single dependency prior to installing a gem?) Even the embedded assumptions like e.g. the Rubygems server is, as of this instance, being operated by Rubygems and not being operated by The Adversary are really, really tenuous.

webreac 14y ago

I really like instructions like this because I understand easily what needs to be done. Probably the content of the script will also be easy to read. Of course, I will never do a copy paste of these instructions. I will redirect to a file and read it before executing. And if I have doubts, I launch a VM.