Make WordPress Core

Opened 11 years ago

Closed 5 years ago

#25052 closed enhancement (duplicate)

Updates and downloads should be signed

Reported by: samuelsidler's profile samuelsidler Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Upgrade/Install Keywords: needs-patch
Focuses: Cc:

Description

Spin off from #18577.

We should sign updates and downloads (including themes and plugins).

Change History (20)

#1 @wycks
11 years ago

  • Cc bob.ellison@… added

+1 Would this be a secure API call or a copy/paste from wordpress.org? The latter probably being less of an issue, for example a button the prompts for the pasted hash from wordpress.org and then does a check.

#2 @bpetty
11 years ago

  • Cc bpetty added

#3 @toscho
11 years ago

  • Cc info@… added

#4 follow-up: @dd32
11 years ago

  • Milestone changed from Awaiting Review to 3.7

Marking as 3.7 for review.

+1 Would this be a secure API call or a copy/paste from wordpress.org? The latter probably being less of an issue, for example a button the prompts for the pasted hash from wordpress.org and then does a check.

I'm not 100% on the cryptographic's behind it, but one suggestion that's been given to me is that we'd include a pre-shared public key in WordPress, we'd sign packages (Core, Plugin, and, Theme zip's) on the server-side with a private key allowing WordPress to verify the package source.
Another option is that the Zip contains a signed hash of the files contained within, and that's what's verified.

There would be no user interaction in the verification process.

This signing may not be needed however, as it would effectively duplicating the HTTPS efforts in #25007 - The checks done there verify that the URL the packages are being downloaded from (if HTTPS, which is the default for 3.7+ if the local WordPress install supports it) have a valid SSL certificate for the *.wordpress.org domain.
However, there is the possibility that someone could get their own wordpress.org certificate from a compromised trusted CA or from a signing agency that doesn't verify things correctly.. To combat that, we can Pin the WordPress.org SSL certificate so that we're guaranteed that the HTTPS connection is to WordPress.org - #25252
With that in mind, Any package signing may not bring anything extra to the table.

#5 in reply to: ↑ 4 ; follow-up: @samuelsidler
11 years ago

Replying to dd32:

With that in mind, Any package signing may not bring anything extra to the table.

I was under the impression that package signing would be done to account for installs that fall back to HTTP when SSL is broken on their servers. I'm not sure if that's even possible however – if SSL is broken, verifying a package likely wouldn't work either.

#6 in reply to: ↑ 5 ; follow-ups: @bpetty
11 years ago

Replying to samuelsidler:

Replying to dd32:

With that in mind, Any package signing may not bring anything extra to the table.

I was under the impression that package signing would be done to account for installs that fall back to HTTP when SSL is broken on their servers. I'm not sure if that's even possible however – if SSL is broken, verifying a package likely wouldn't work either.

I think this is mostly correct, unless package signing uses a different type of certificate/encryption that can be supported even when HTTPS certificate verification fails. I don't think it's worth looking into that incredibly small window assuming it exists though.

I've considered bundling another 3rd party library, namely phpseclib, which provides a pure-PHP X.509 and PKCS#1 implementation (while being license and PHP version requirements compatible), however, it really is a huge library, and I'm also opposed to adding yet another custom maintained 3rd party library that requires being stripped down, files renamed, and some minor code changes like most of the other bundled libs - especially on a library whose sole purpose is security and encryption.

I do want to dispel a couple wrong assumptions here though.

Even if the HTTPS efforts in #25007 are perfect and work 100% of the time, that does not mean that package signing is pointless, even if package signing is only ever done on the WP.org repositories. If we're smart about this, an ideal solution would use the strengths of both approaches to combat two different types of vulnerabilities.

For example, if we were lazy, and only signed packages with one authority, WP.org, but the signed packages were easily verified against one signature that could be bundled with WordPress, *then* implementing that whole system would only protect against the exact same issues we are fighting by implementing HTTPS certificate verification. This also would likely have some implications that might make it difficult or impossible for those gains with premium plugins/themes.

If we aren't lazy (and this would take significantly more work to implement, both on our part, and on plugin/theme authors), we implement package signing through the authors themselves in the same way that Android apps, OSX apps, and many other software distribution channels handle package/application signing.

The pros:

You need to look at package signing outside the use of that first plugin or theme installation. You can implicitly trust the package signature on first installation (assuming we never even handle certificate verification - if we can though, that's even better), and still gain heavy security benefits from it for all future updates.

If a plugin update comes down that doesn't match the existing plugin's certificate, we can refuse to update. That would stop someone from stealing one of the Jetpack plugin committers' credentials and uploading a compromised update for example. Android apps do this, and we don't get this benefit with WP.org HTTPS alone.

The cons:

Performing certificate verification (validating that the certificate came from the correct owner) is significantly more difficult, and in some cases impossible to enforce as is the case with Composer right now because of the wide range of software sources supported. Where do you maintain an authoritative list of what certificate belongs to which package? How about for premium plugins and themes? Linux distros have a tiny web of trust, and can distribute the public keys with the install media directly. We might be able to gather some insight on a solution for this from Pyrus though (the new PEAR installer), which claims to support this.

Additionally, it would be incredibly stupid to generate individual private keys for all authors on WP.org in order to automatically sign packages for them, but the alternative requires that the authors create the zip package on their local machines themselves, and that completely conflicts with the plugin/theme review system and bypasses SVN entirely for plugins (it could still easily work for themes though). So there's that.

#7 in reply to: ↑ 6 ; follow-up: @dd32
11 years ago

Replying to samuelsidler:

I was under the impression that package signing would be done to account for installs that fall back to HTTP when SSL is broken on their servers. I'm not sure if that's even possible however – if SSL is broken, verifying a package likely wouldn't work either.

Correct, if we release with a bundled CA (#25007) then any system that can use OpenSSL should "just work" for HTTPS communication, any host that doesn't have OpenSSL most likely wouldn't be able to verify a package signature either (Unless we packaged phpseclib or used a non-SSL based method of signing)

Replying to bpetty:

If we aren't lazy (and this would take significantly more work to implement, both on our part, and on plugin/theme authors), we implement package signing through the authors themselves in the same way that Android apps, OSX apps, and many other software distribution channels handle package/application signing.

To be blunt, I don't think this is something that we'll be implementing at present (user initiated signing), it's a lot of extra work for "minimal benefit".
Peoples credentials falling into a malicious user's hands is probably not something that should be fixed through code either, instead, 2 factor authentication (for svn, that'd likely require svn+ssh://) or email-confirmation-of-releases would be more appropriate.

For non-WordPress.org hosted items, package signing could be much more useful, however, is something that the plugin handling that could add.
If we supported multiple repositories, which were only partially trusted, package signing would be much more crucial, so as to prevent one repository claiming to have an updated version for something which it doesn't have the authority to offer - Something that I believe Linux / Pear / Composer / Android probably has to deal with.

So in conclusion: I think #25007 ( optionally with #25252 ) is going to provide us enough of a security boost for 3.7.
I also think that we should still look into making a package signature available for downloads somehow, even if we don't utilise them within WordPress quite yet.

#8 in reply to: ↑ 6 @rmccue
11 years ago

I agree with bpetty and dd32's assessment, but I'd like to note:

Replying to bpetty:

I've considered bundling another 3rd party library, namely phpseclib, which provides a pure-PHP X.509 and PKCS#1 implementation (while being license and PHP version requirements compatible), however, it really is a huge library, and I'm also opposed to adding yet another custom maintained 3rd party library that requires being stripped down, files renamed, and some minor code changes like most of the other bundled libs - especially on a library whose sole purpose is security and encryption.

dd32 has expressed interest in bundling the library to improve SSH/SFTP support as part of integrating the existing plugin into core. Whether that happens is a separate issue, but worth noting that it wouldn't just be for this feature.

+1 for dot-org signatures now for core at least, plugins once the architecture supports it. Having it means we can start to integrate it into core as a separate issue.

#9 in reply to: ↑ 7 @bpetty
11 years ago

Replying to dd32:

To be blunt, I don't think this is something that we'll be implementing at present (user initiated signing), it's a lot of extra work for "minimal benefit".

Well, I don't think it's "minimal benefit", but I do agree that there's huge problems in the architecture of how the plugins repository works that make this impossible right now, and I certainly don't see those being solved anytime in the next year or two. Sorry if I didn't make that clear earlier.

Peoples credentials falling into a malicious user's hands is probably not something that should be fixed through code either, instead, 2 factor authentication (for svn, that'd likely require svn+ssh://) or email-confirmation-of-releases would be more appropriate.

That's cool too (see #meta77), but there's nothing wrong with using both (and again, they both still cover different attack vectors and uses).

So in conclusion: I think #25007 ( optionally with #25252 ) is going to provide us enough of a security boost for 3.7.
I also think that we should still look into making a package signature available for downloads somehow, even if we don't utilise them within WordPress quite yet.

Yeah, I think this is good for now. To be clear, I think deciding on how packages should be signed, and signing core packages are a great start.

I don't think that plugins or themes should be signed at all right now. It wouldn't be fair to sign WP.org plugins and themes with a WP.org key that would lock us into never allowing author-signed packages in the future even if we could eventually, especially when as you pointed out, it won't actually provide any benefit.

#10 @dd32
11 years ago

  • Keywords 2nd-opinion removed
  • Milestone changed from 3.7 to WordPress.org

This seems to be a #meta ticket now & closed as maybelater ?

#11 @samuelsidler
11 years ago

Part of it is #meta (the signing and serving), but doesn't core need to support the signed packages?

#12 @dd32
11 years ago

  • Milestone changed from WordPress.org to Future Release

Yes, The primary focus is now #meta, and this ticket can go live in Future Release or be closed as maybe later.

#13 @sarciszewski
9 years ago

  • Keywords needs-patch needs-docs added
  • Version set to trunk

I'm taking over this one. Should have a first round patch ready by Sunday for consideration to be included in 4.1.1 or 4.2 (whichever the next release is).

#14 @johnbillion
9 years ago

  • Keywords needs-docs removed
  • Version trunk deleted

I would discuss this with the WordPress.org API team (primarily @dd32) before putting too much time into it.

#15 @sarciszewski
9 years ago

I've already been discussing it with @dd32 and @nacin via email.

#16 @sarciszewski
7 years ago

Recommended reading: https://paragonie.com/blog/2016/10/guide-automatic-security-updates-for-php-developers#elements-automatic-updates

I'm no longer contributing to WordPress core due to disagreements that aren't really up for discussion here.

This ticket was mentioned in Slack in #core by paragonie. View the logs.


7 years ago

#18 @paragoninitiativeenterprises
7 years ago

#39309 discusses the wider problem of secure updates (it's bigger than just offline signatures, which is what's discussed in this ticket).

#19 @paragoninitiativeenterprises
5 years ago

This ticket can now be closed, since #39309 is now closed. The fix will land in 5.2.

If @dd32 or another core dev has the power to mark this ticket appropriately, I'd greatly appreciate it.

#20 @SergeyBiryukov
5 years ago

  • Milestone Future Release deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of #39309.

Note: See TracTickets for help on using tickets.