6 ms·

That's a pretty common thing. I don't see the problem.

by ruswick 11y ago

sarciszewski 11y ago
Hack their webserver, replace the contents of https://install.meteor.com/ https://install.meteor.com/ with malware, instantly pwn anyone who pipes that to their shell. Worse: the people who are most likely to curl|sh are DevOps folks with the keys to their company's kingdom.
- honest_joe 11y ago
  Commit a race condition to glibc,musl,uclibc and fuck up almost every software on the planet. It's convenient and that does not mean it's a good practice but i doubt using an other method would minimize a risk when the meteor.com would actually get owned.
  - sarciszewski 11y ago
    > i doubt using an other method would minimize a risk when the meteor.com would actually get owned. GPG signing, keep the private key offline, publish the public key in the blockchain and have a lot of high profile technologists sign it so it can be independently verified. See also: PHPUnit. https://phpunit.de/manual/current/en/installation.html#installation.phar.verification https://phpunit.de/manual/current/en/installation.html#insta... (They provide an example shell script for quickly downloading and verifying the latest versions of their install)
    - honest_joe 11y ago
      I completely understand your point. But at the end it's about people ...your example with PHPUnit can be abused like this https://thejh.net/misc/website-terminal-copy-paste https://thejh.net/misc/website-terminal-copy-paste How many people do you think will bother to paste the script to a text editor and check for evil parts ?
      - sarciszewski 11y ago
        Anybody who runs unverified code, through any medium, when the option to run trusted code is available, deserves to get pwned. https://github.com/paragonie/password_lock/blob/master/run-tests.sh https://github.com/paragonie/password_lock/blob/master/run-t... ^- For the record, I keep scripts like this in my Git repositories.
- logicallee 11y ago
  What do you want them to do? The obvious solution is to change it from "curl|sh" to "curl|{something about whetehr PGP says this is properly signed by the private key belonging to public key blahblahblahblahbalhMETEOR.COMkey. If yes:}|sh" But the problem is anyone compromising the site can just change the line from "blahblahblahblahbalhMETEOR.COMkey" to "attackerchangedblahblahblahblahbalhMETEOR.COMkey" right on the web page, and people will copy the one verified against the wrong key. So that doesn't work. Nor do clients have caches of PGP signatures, nor is there some totally obvious third-party that you can verify it with. You can't just go: curl|{check_if_signed_with_www.this-site.com}|sh (which would pass visual inspection - the attacker would have to change www.this-site.com to something else) because there is no obvious mechanism to do that. Who will tell you whether https://install.meteor.com/ https://install.meteor.com/ has signed it? Well, HTTPS will kind of tell you. So "https://install.meteor.com/" https://install.meteor.com/" is a lot better than nothing... If you're going to entertain the idea of the HTTPS site being compromised to serve whatever they want, well, there is precious little you can do about it.
  - sarciszewski2 11y ago
    > What do you want them to do? I want them to not use a one-liner. Step-by-step: 1. Download the files 2. Download the public key 2a. verify the public key if you've never seen it before (publish in the blockchain, have lots of high profile technologists sign it, etc) 3. If the verification matches, then proceed. Teaching developers to value "clever one-liner hack" over "secure, dependable solution" will lead to bad habits.
    - logicallee 11y ago
      if you're going to include "2a" you can refactor all of your steps into: 1. Google "meteor.com compromised" and decide whether it's currently compromised. If it isn't: 2. Run curl https://install.meteor.com|sh https://install.meteor.com|sh It saves a few steps and is equally secure - you know, since you're just going to go based on what other people think and include no programmatic check whatsoever. (your 2a).
- deleted 11y ago
  [deleted]
joepie91_ 11y ago
It being a common thing is the problem. It's teaching insecure habits.
- sarciszewski 11y ago
  People are downvoting this and being too much of a coward to state why they are.
  - vdaniuk 11y ago
    I am downvoting them because shell piping is not relevant to Meteor 1.2 announcement, this topic was discussed on multiple occasions and they offer no alternative.
    - sarciszewski2 11y ago
      Sure it's relevant. They're announcing "hey we have these new features" and I'm saying "hey look, they still haven't fixed this big glaring problem that is very much relevant to how their software is used".
  - maratd 11y ago
    Downvoting because it's a non-issue. If I'm copying and pasting something from the web into my terminal, it's because I trust the source. It's not any less secure than downloading a tarball and running scripts inside of it. That's equally insecure and people have been doing that since the dawn of the internet.
- logicallee 11y ago
  What do you think about this solution: introduce a layer on top of SSL that just verifies whether the private key of a certain explicitly stated site has signed a file? In other words, compromising the server wouldn't be enough, because that doesn't give you the SSL key, so it would still fail "curl|is_signed_by site.com|sh", which they can only pass if they compromise the private key? Better than the current system?
mcgaffin 11y ago
Docker addressed this last week at dockercon, announcing Docker Notary to securely publish and verify content. https://github.com/docker/notary https://github.com/docker/notary

That's a pretty common thing. I don't see the problem.

by ruswick 11y ago

That's a pretty common thing. I don't see the problem.

Hack their webserver, replace the contents of https://install.meteor.com/ https://install.meteor.com/ with malware, instantly pwn anyone who pipes that to their shell. Worse: the people who are most likely to curl|sh are DevOps folks with the keys to their company's kingdom.

honest_joe 11y ago
Commit a race condition to glibc,musl,uclibc and fuck up almost every software on the planet. It's convenient and that does not mean it's a good practice but i doubt using an other method would minimize a risk when the meteor.com would actually get owned.
- sarciszewski 11y ago
  > i doubt using an other method would minimize a risk when the meteor.com would actually get owned. GPG signing, keep the private key offline, publish the public key in the blockchain and have a lot of high profile technologists sign it so it can be independently verified. See also: PHPUnit. https://phpunit.de/manual/current/en/installation.html#installation.phar.verification https://phpunit.de/manual/current/en/installation.html#insta... (They provide an example shell script for quickly downloading and verifying the latest versions of their install)
  - honest_joe 11y ago
    I completely understand your point. But at the end it's about people ...your example with PHPUnit can be abused like this https://thejh.net/misc/website-terminal-copy-paste https://thejh.net/misc/website-terminal-copy-paste How many people do you think will bother to paste the script to a text editor and check for evil parts ?
    - sarciszewski 11y ago
      Anybody who runs unverified code, through any medium, when the option to run trusted code is available, deserves to get pwned. https://github.com/paragonie/password_lock/blob/master/run-tests.sh https://github.com/paragonie/password_lock/blob/master/run-t... ^- For the record, I keep scripts like this in my Git repositories.
logicallee 11y ago
What do you want them to do? The obvious solution is to change it from "curl|sh" to "curl|{something about whetehr PGP says this is properly signed by the private key belonging to public key blahblahblahblahbalhMETEOR.COMkey. If yes:}|sh" But the problem is anyone compromising the site can just change the line from "blahblahblahblahbalhMETEOR.COMkey" to "attackerchangedblahblahblahblahbalhMETEOR.COMkey" right on the web page, and people will copy the one verified against the wrong key. So that doesn't work. Nor do clients have caches of PGP signatures, nor is there some totally obvious third-party that you can verify it with. You can't just go: curl|{check_if_signed_with_www.this-site.com}|sh (which would pass visual inspection - the attacker would have to change www.this-site.com to something else) because there is no obvious mechanism to do that. Who will tell you whether https://install.meteor.com/ https://install.meteor.com/ has signed it? Well, HTTPS will kind of tell you. So "https://install.meteor.com/" https://install.meteor.com/" is a lot better than nothing... If you're going to entertain the idea of the HTTPS site being compromised to serve whatever they want, well, there is precious little you can do about it.
- sarciszewski2 11y ago
  > What do you want them to do? I want them to not use a one-liner. Step-by-step: 1. Download the files 2. Download the public key 2a. verify the public key if you've never seen it before (publish in the blockchain, have lots of high profile technologists sign it, etc) 3. If the verification matches, then proceed. Teaching developers to value "clever one-liner hack" over "secure, dependable solution" will lead to bad habits.
  - logicallee 11y ago
    if you're going to include "2a" you can refactor all of your steps into: 1. Google "meteor.com compromised" and decide whether it's currently compromised. If it isn't: 2. Run curl https://install.meteor.com|sh https://install.meteor.com|sh It saves a few steps and is equally secure - you know, since you're just going to go based on what other people think and include no programmatic check whatsoever. (your 2a).
deleted 11y ago
[deleted]

joepie91_ 11y ago

It being a common thing is the problem. It's teaching insecure habits.

sarciszewski 11y ago
People are downvoting this and being too much of a coward to state why they are.
- vdaniuk 11y ago
  I am downvoting them because shell piping is not relevant to Meteor 1.2 announcement, this topic was discussed on multiple occasions and they offer no alternative.
  - sarciszewski2 11y ago
    Sure it's relevant. They're announcing "hey we have these new features" and I'm saying "hey look, they still haven't fixed this big glaring problem that is very much relevant to how their software is used".
- maratd 11y ago
  Downvoting because it's a non-issue. If I'm copying and pasting something from the web into my terminal, it's because I trust the source. It's not any less secure than downloading a tarball and running scripts inside of it. That's equally insecure and people have been doing that since the dawn of the internet.
logicallee 11y ago
What do you think about this solution: introduce a layer on top of SSL that just verifies whether the private key of a certain explicitly stated site has signed a file? In other words, compromising the server wouldn't be enough, because that doesn't give you the SSL key, so it would still fail "curl|is_signed_by site.com|sh", which they can only pass if they compromise the private key? Better than the current system?

mcgaffin 11y ago

Docker addressed this last week at dockercon, announcing Docker Notary to securely publish and verify content. https://github.com/docker/notary https://github.com/docker/notary