Hacker News Reader

Hacker News

Comment by aw3c2 | Hacker News Reader

Parent Full thread

aw3c2

curl -s http://getcomposer.org/installer | php

is creepy. Never ever run other people's code without at least giving it a glance.

View on HN

Reminds me of how you get mysqltuner:

wget mysqltuner.pl

perl mysqltuner.pl

(Yes, they actually have a .pl domain for it)

RVM's installation is similar:

https://rvm.io/rvm/install/

A far cry from the safer/verified "download this and check it's MD5 checksum" method that I'd prefer.

Seriously, fixing package management so we can continuously integrate arbitrary code would be great. Getting arbitrary OS package creation to be almost as easy as pushing code to GitHub seems like a very worthy goal.

md5 is not going to protect you from much, especially if the md5 checksums are hosted on the same server.

Also, pushing random code via apt-get is not going to win you any sysadmin friends. They like their servers to be stable, and their packages to be well tested.

Seeing as you can remove said code via apt, you'd likely win them over compared to the alternative of being told to install compilers or some other non package managed software bundler like cpan/rvm/npm that can't be canned and easily deployed.

But why would you remove it? Because whatever you've installed has broken.

Much better not to be broken in the first place.

It seems you live in an idyllic world far, far away from reality.

It's not the nineties anymore, MD5 doesn't protect you from much, and especially not from the author of the original package creating an alternate version.

Viable verification is based on an unbroken hash (preferably SHA-(256|384|512), but SHA1 still not broken even it it's definitely too short nowadays. And the hashes need to be distributed properly, either PGP signed or hosted on a trusted TLS protected site...

Yet many projects still distribute MD5 hashes, thinking it got any value.

For the longest time the installation instructions for NPM were almost exactly the same. But its worse when PHP does it :)

In terms of security this is no different than executing someones binary or building a big code base.

Indeed, especially coming after this further up the page:

> Never ever (ever) trust foreign input introduced to your PHP code.

Where'd I put that sense of irony...

Except that there's a significant difference between "trust" of input from the user vs. "trust" of the software stack you use as a foundation.

Unless you've read every line of the Linux kernel, we all succumb to the later point sooner or later.

If you don't like that command, do this instead:

    > curl -s http://getcomposer.org/composer.phar -o $HOME/local/bin/composer ; chmod +x $HOME/local/bin/composer

Assuming that $HOME/local/bin is in your $PATH, the current user will have a "composer" command available.

Yeah... only idiots "sudo aptitude install" without reading and building from source first!

You really can't tell the difference between blindly executing input from an insecure HTTP connection, and installing packages with a tool that verifies cryptographic signatures against known good keys shipped with your distro?

Mr. Cantor, I have added to the list of people to never hire I keep in my notebook.

You can explain the difference without attacking the person you're replying to.

The risk of picking up malicious executable from the legit server is far higher than that of picking up a malicious executable from an impersonating server. Practically speaking.

So? Who says the verified package isn't malicious? My point isn't about cryptography, it's about complexity. Unless you personally read through every line of code, how do you really know that there isn't something in there waiting to screw you over?

I trust my system's package maintainers and the signing makes sure that it is them.

I do not trust a random website that could easily be MITMd.

So you'd be fine with https?

You don't know. What you know however is who to sue if the package ends up being malicious, thanks to the signature.

And I've added you to the list of guys that think they are "the shit" because they have hiring abillities (in some shitty company) and need to tell it on the intertubes.

haha. Always good advice. But I checked. It's fine :)

It's fine now until someone hacks their site or poisons their DNS.

Or writes a script which checks the user agent and only serves up malware to curl.

Or the second time that an IP address hits it.

Or something else that you haven't thought of.

Update: Such as doing something nasty to http://getcomposer.org/composer.phar instead - a 520KB php file that the first script downloads and runs without even md5ing first. Did you audit that too? Did you understand everything that it was doing?

Or social engineers their registrar and changes their dns.

That's really just a question of trust. If you know what Composer is, you trust it.

'apt-get install whatever' is just as magically scary and dangerous.

No it isn't, there's GPG signing and things going on there.

  No it isn't, there's GPG signing and things going on there.

That's really just Cargo Cult security, isn't it? Signed packages can just as easily be malicious. In fact a repository server could be a much worthier target for the injection of bad code than a single, relatively obscure web project.

The repository doesn't have any access to the developer's private key. That's exactly the attack that they're designed to mitigate.

The difference is the same as between http and https.

Exactly. SSL doesn't guarantee that the content is benign either. But there is also a key difference when it comes to software distribution. On a typical web connection you worry about 3rd parties observing your content and maybe even spoofing it later (e.g. stealing your cookies), but as far as downloads are concerned your main worry is actually content integrity. This integrity is threatened by both malicious publishers and outside attackers injecting malicious code into otherwise benign software - having a GPG signature alongside your rpm does (almost) nothing to mitigate that risk.

Not sure if you are trying to make a joke (and if so, it's incredibly subtle), or you are being serious. In case you are serious, to explain how HTTPS as it's used means anything about the trust-worthiness of the two parties involved?

Look at the original post. "curl -s http://getcomposer.org/installer | php" It's not just about trusting Composer, it's about trusting every point between you and their server. If I want to know that I am actually executing Composer I need to use a secure download method.

I don't disagree with you, but if you've got someone actively trying to exploit you sitting between you and the Internet, you've got bigger problems.

Someone trying to find an exploit is a bigger problem than giving them one?

Oh, definitely. If someone has a launched a targeted attack against you and they already have the ability to seamlessly view and modify your internet traffic, you are in pretty serious trouble whether you download your development tools from wget or apt-get.

Except that apt-get will check GPG signatures and detect that kind of attack. How is a MITM attack going to find a 3rd party's private key?

I'm looking at the post you replied to. So maybe you replied to the wrong post, or ignore context and tried to be witty or smart.

In context, what you say makes no sense.

Regardless, https would be better, but if you are that nervous as you suggest you are, then https doesn't solve your problem either. Neither does some hash thrown up on some site for you to compare against.

Here, how about I summarize my view of the conversation for you.

  aw3c2: 'curl | php' is creepy
  timaelliott: apt-get is just as scary
  kudos: no, it has signing
  udo: that's cargo cult
  me: no, it protects like https (meaning it authenticates and stops MitM)

I was responding perfectly in context to point out how the protections apt-get have are useful. I also tied it back into the original comment but you can ignore that part if you like. I don't know why you think I was 'trying to be witty' and ignoring context.

Ahh, gotcha, that better explains it.

Still, https doesn't validate anything. You could add a certificate, but then that only means you are talking to the server assigned the cert, not that the actual package is good.

I still stand by what I said: mountain and mole hills.

It does not help you if the originating server has been hacked, which is by far the most likely attack vector (after people being assholes on the internet or making mistakes in their script).

Protecting against that is the whole fucking point of using things like apt-get/PEAR and GPG/code signing.

Signed packages can be just as malicious, but the security of the mechanism relies on the signer not wanting to do jail time, thus protecting his secrets and not signing stuff he doesn't trust.

Reply on news.ycombinator.com