[RFC] Secure Automatic Upgrades

[TerraFrost]

If you've ever used Wordpress, you're probably aware of how, when a new version is released, Wordpress can automatically download and install the update for you. As convenient as that is, it does present a small problem. In particular, if phpbb.com or wordpress.com or whatever were hacked, an attacker wouldn't just be compromising phpBB - they'd be potentially compromising most every phpBB install out there.

The solution is to use signed patches. phpBB's public key would be included with every phpBB install and all phpBB releases would be signed with phpBB's private key. phpBB would automatically download the latest release, verify the signature and only if it matches would it install it. This can be done without imposing any additional requirements on the server by using phpseclib's Crypt_RSA library.

Here's the RFC:
http://wiki.phpbb.com/PhpBB4/RFC/Secure ... c_Upgrades

Please post here if you make any changes - thanks!

[Oleg]

What if the signature checking code contains a bug and does not work correctly? What if there is a bug allowing signature checking to be bypassed? What if the signature itself happens to be weak (see Debian ssl vulnerability)?

Giving code write access to itself is dangerous. It is unfortunately inevitable to some degree with php due to how typical php servers are setup, but please make this feature completely optional. It is convenient, and automatically installing signed updates is more secure than automatically installing arbitrary code, but either case is less secure than a properly configured environment where automatic updates are not possible.

[igorw]

Such a system can make things a lot easier for administrators. Using some form of cryptography is certainly a must. It must also be failsafe, in a way that it can easily be reverted to a backup in case something goes wrong.

It would be good to have a secure channel to obtain the public key/package checksums, since the package may be mirrored. Perhaps over SSL?

[TerraFrost]

What if the signature checking code contains a bug and does not work correctly? What if there is a bug allowing signature checking to be bypassed? What if the signature itself happens to be weak (see Debian ssl vulnerability)?

The signature checking code is fairly well vetted. You can verify at least RSASSA-PKCS1-v1_5 signatures by using RSA authentication in phpseclib's Net/SSH2.php. I'm thinking it'd be better to use RSASSA-PSS as defined in PKCS#1 v2.0+ but phpseclib's RSASSA-PKCS1-v1_5 implementation is certainly more vetted than it's RSASSA-PSS implementation. Maybe there's some obscure bug that only manifests itself under really rare conditions but the code is pretty straight forward.

As for there being a bug in phpBB4's yet-to-be implemented signature verification routines... it's hard to comment on something that hasn't been implemented.

As for the Debian SSL vulnerability... correct me if I'm wrong, but that was relating to key creation - not to signature verification - was it not? More to the point, I believe the problem was that the random number generator used generated comparatively easy-to-predict keys.

Giving code write access to itself is dangerous. It is unfortunately inevitable to some degree with php due to how typical php servers are setup, but please make this feature completely optional. It is convenient, and automatically installing signed updates is more secure than automatically installing arbitrary code, but either case is less secure than a properly configured environment where automatic updates are not possible.

Such a feature would have to be optional unless phpBB4 shipped with the requirement that it be installed in a publicly writable directory (which would be silly). Wordpress doesn't even have that requirement. With Wordpress, you're prompted, if you chose to pursue this upgrade route, for login info. With phpBB4, under this proposal, you'd be asked for that same thing. phpseclib has a pure-PHP SFTP implementation that could be used for SFTP servers and pure-PHP FTP implementations are common enough (phpBB3 has one, for example).

It would be good to have a secure channel to obtain the public key/package checksums, since the package may be mirrored. Perhaps over SSL?

I don't see downloading the updates over https as being necessary. https just ensures that people can't eavesdrop and that's not really a concern here, anyway. The goal, here, isn't confidentiality - it's integrity.

It's kinda like... when you download Apache, you can download PGP signatures to verify the integrity of the package you downloaded even though the download, itself, isn't done over https.

[igorw]

I'm not talking about a secure channel for transmission of packages. I'm talking about a secure channel for the public key. So you can at least verify it has not been tampered with, after you obtain the package.

[naderman]

This definately makes sense. But maybe we should look at this in a more generic context, the same methods should be applied to plugins.

I'm not talking about a secure channel for transmission of packages. I'm talking about a secure channel for the public key. So you can at least verify it has not been tampered with, after you obtain the package.

We do provide checksums for our packages, so if you really download the original package from an insecure location where it could be exchanged by a man in the middle you could at least download the checksum through an alternate channel. But still HTTPS for that wouldn't hurt. But I think that's more of an administrational question for phpbb.com that we should look into.

[naderman]

It would appear that the hash() function should be available on all PHP5.3 installations, if I'm not misunderstanding the documentation there. So instead of the sha1 hash you propose we could use sha256 or something else entirely. I have no idea what the best choice is for something like this.

[TerraFrost]

Nice catch! I've updated the RFC to say SHA256 but any algorithm supported by hash() should work. phpseclib doesn't support all the algorithms that hash() does but I figure I'll update that at some point.

Whirlpool was designed by the people who did AES. It's best cryptanalysis (according to it's wikipedia article) seems to require more operations than any of those discussed here:

http://en.wikipedia.org/wiki/Comparison ... _functions

Given that, I'm actually leaning towards Whirlpool.

[EXreaction]

How does using signed patches prevent compromising the download files if the phpbb.com server were to be hacked?

If the phpbb.com server were compromised, wouldn't an attacker be able to change the public/private keys anyways?

[TerraFrost]

The only thing they'd be able to change would be the signature. The public keys would be included in each phpBB install and although downloads made while the hacked website was up could have altered public keys, already deployed installations would not.

The private key, presumably, wouldn't be stored on the server but on the hard drives of various developers or Management Team members or whatever. Or maybe they could just be stored on USB sticks, or something, only plugged into a computer when needed. They'd also, in theory, be encrypted with a symmetric key algorithm as well. phpseclib supports private keys encrypted with DES and 3DES. PuTTY private keys support AES, as well.

Certainly a developer machine could be compromised, as well, but that, presumably, wouldn't be nearly as easy as compromising a website. Consider phpbb.com, for example. Hosted in Oregon and remotely administered (well, unless there's a team member I don't know about living in Oregon), it no doubt has several open ports. Open ports that you and I don't need open on our own personal machines since they're, in all likelihood, going to, physically, be in the same room as us. So that limits the range of attacks one can use against a personal machine right off the bat. Also, hacking a Team members machine isn't as easy as going to phpbb.com. You have to first get their IP address and that, itself, may not be all that easy. I mean, I guess you could use social engineering - you could try to trick a Team Member into replying to an email you sent them or something - but, then again, you could just thwart all that by putting the private key on a USB stick that's only ever plugged in when a release needs to be made.