Remote Code Execution Vulnerability via MITM.

[StormTide]

Composer runs code from HTTP sources without validating the source of the download or the code downloaded. As such, trivial man-in-the-middle attacks through any number of vectors (dns, networking, local server exploit, etc) will result in execution of code of an attackers choosing at the userlevel of the user running composer. (Typically a developer account)

Example command to reproduce. (User)

php composer.phar self-update

src/Composer/Command/SelfUpdateCommand.php lines 45, 50 and 59 are key.

Exploitation:

Replace getcomposer.org for a given network perspective by replacing it with a malicious http instance (eg by changing the DNS locally, at the lan, at an isp or hosting provider dns resolver, or globally or equally easily by replacing a route to the legitimate server (eg arpspoof)) . The http server instance is configured to serve a malicious /composer.phar and a /version url that produces random data. When users run self-update, the malicious code will be downloaded and run as the user that is executing the self-update command.

The same technique can be used for any package configured over http.

Fix:

Disable HTTP scheme's in composer and implement TLS or redesign composer to support digital signatures. (See AptSecure)

[Seldaek]

Doing secure HTTPS in php is unfortunately not as easy as it should be. Basically we'd have to ship our cert pubkey (or at least our CA's) within the sources, which means that at some point the old composer code would stop working if the cert changes. I'm not sure how to work around that yet, so for now we run in insecure mode (and let's be honest.. there are many many ways you can be in trouble if someone can MITM your machine, which is not to say it shouldn't be fixed)

[Seldaek]

I guess what might be a better solution than just relying on SSL is to do something similar as ssh does with the known_hosts, where we'd host the public key on packagist, and the first time if you don't have it on your machine it asks you whether you trust it (or maybe we do it silently if you don't have the domain yet) then if it changes you get a big fat warning. Then we could use the private key to sign everything else, and have the client verify it using the trusted pubkey. How does that sound?

[EvanDotPro]

...and the first time if you don't have it on your machine it asks you whether you trust it (or maybe we do it silently if you don't have the domain yet) then if it changes you get a big fat warning.

Silently accepting new keys is a bad idea. You should always prompt the user to add new keys, showing the fingerprint to the user. The fingerprint should also be available for confirmation via a valid, trusted https:// address.

[EvanDotPro]

(Sorry if anyone subscribed to this thread got an e-mail with an incomplete version of this message before.)

Disclaimer: I am by no means a security expert. I like to think I know the basics, but I welcome (and encourage) those who know better to correct anything I miss or don't get quite right.

This is an issue I've been discussing with the Zend Framework 2 community for several months and is the primary reason I cannot, in good conscience, recommend using Composer+Packagist to my peers yet. I'd really like to see security taken seriously and improved soon if we want Composer+Packagist to be a viable de facto standard in the PHP community. I'll go as far as to say that it worries me that Composer has become so popular without something so obvious being addressed.

In an ideal world, what I'd like to see, instead of securing the transport layer, is proper support for repository-level package signing and/or the ability for users to add authors' public keys to their trusted keys so that they (or Composer) can verify the validity of packages downloaded. We've seen this model for decades in Linux distros and other communities, and for good reason -- it's proven secure and it works. This way you are not tied to only downloading via SSL from trusted domains. It opens the possibility for people to host and use mirrors safely and securely without relying on each mirror to properly purchase and install a valid, properly signed SSL certificate and for users to add the public key of each server or mirror they wish to use. The Linux model is generally one canonical repository, one public key. With the content of the packages signed and verified, you no longer have to worry about the integrity and security of the transport layer. Public FTP? No problem. Insecure HTTP? No problem. Packages are signed so it doesn't matter.

The ideal solution to this is PGP; however PHP doesn't make PGP easy to implement in a cross-platform way. In order to use PGP, we'd have to require they have gpg installed and on their path (a pain on Windows) and build packages into phar/tar/zip/etc, and use detached signature files, as Phar only seems to support OpenSSL built-in signatures (and worse, if OpenSSL is not available, I've heard it silently falls back to a SHA-1 checksum, though I've yet to verify this in php-src). I've posted on php-internals about PGP Phar support, but no one seems to know what happened to that -- there's hints it was meant to get in but never made it. For packages where a Git repository is the source, we would want to, by default, only allow checking out signed tags, which can be verified with a trusted public key. For the sake of usability, you could make exceptions, allowing Composer to check out unsigned tags if they specifically have Github's public key trusted and the source is from https://github.com/, etc.

Of course, this brings with it plenty of other logistic issues like managing the repository's private key -- if you're allowing user-submitted and updated packages, you'll need to automate the signing of they packages. Great care would need to be taken to keep the signing server segregated and secure so the repository's private key does not get compromised. There are folks smarter than myself that could probably offer specific advice regarding that.

Unfortunately, I don't see Composer / Packagist actually implementing package signing; it would be a lot of work and require some redesigning of the Composer client and the Packagist backend, as well as overcoming some logistical issues that may, at first glance, seem insurmountable. So, if we're going to settle for a compromise, then yes, everything needs to default to SSL, and care needs to be taken that the SSL certificate is valid and trusted, as we all know PHP's default is useless in this regard.

and let's be honest.. there are many many ways you can be in trouble if someone can MITM your machine

Correct me if I'm wrong, but isn't DNS a distributed system, and can be (and has been) compromised at levels beyond just your own network; isn't this why DNSSEC exists? I've always operated under the assumption that you can have a "perfectly" secure server and network, yet still get back a compromised DNS response from upstream and that you should always take additional steps to verify who you're actually connecting to if security is at all a concern (and with a package manager, it is very much so).

Anyway, let's get this taken care of, please.

[StormTide]

and let's be honest.. there are many many ways you can be in trouble if someone can MITM your machine

You can easily MITM anyone on the Internet today. This system is decentralized, and offers thousands of points of attack. Getting in-between any company's developers is often as simple as getting a client on the same WIFI network, running arpspoof and hijacking the IP for getcomposer.org. (Think PHP conference, think firesheep... this isnt complicated stuff)

But more likely, someone will hijack the getcomposer.org dns from some network perspective. Either the entire domain (you're using a high security dns provider right???) or at a big datacenter's dns server. A little client profiling (eg only inject code into clients from a certain network) and its almost undetectable.

Installing unauthenticated packages takes us back a full decade. Theres lots of ways to do authentication, either with TLS setup correctly or with package signing. Silent TOFU wont work and is actually a rather hilarious way to propose solving this problem. (You do verify your host keys when connecting to a ssh server for the first time... riiiight?)

[EvanDotPro]

I've issued a pull request which attempts to address this issue. It's not my ideal fix (see my above comment), but it's probably the next best solution to fully implementing proper package signing.

[till]

Sorry for commenting on an old issue — but I feel like this issue should be addressed. Did anyone make any progress or have any thoughts how to progress?

I personally see how potentially SSL can be a painpoint to the adoption of composer — but then again it could be configurable so people can add CAs if the ones included in code expire. Maybe composer should attempt to use SSL by default and have a configuration option to turn it off?

Maybe packagist should start making everything available over SSL and lead by example?

I wouldn't remove support for http:// entirely though — e.g. on a LAN this may be acceptable. Maybe it should come with a warning though. ;)

On signing packages — that would be great too.

I think the format of the packages.json file could be easily extended to include a signature and it could be checked when available. Kind of how sha1 checksums are currently used. I don't know any cross-platform way to verify this though — it seems pretty straight forward on the Mac, Linux and Unix. But I have no idea about Windows. I'd appreciate pointers though.

[webmozart]

Why isn't this getting more attention? As I see it, this is a very serious security issue. PHP was known for a ignorance and lack of security once, let's not start this again.

[till]

@bschussek Want to comment/work on #1941? I need this fixed/improved as well.

[till]

@odnanref Keep it classy and on topic, please.

[ivan-novakov]

This issue is really disturbing. The solution might be to make the validation optional, so developers, who are aware of the risk and don't mind doing a little extra work, could use it.

[jameshalsall]

@ivan-novakov I'd say that is a bad approach. That's how PHP got it's bad name originally, because it's easy to do things in an insecure fashion