[wp-trac] [WordPress Trac] #39309: Secure WordPress Against Infrastructure Attacks

[WordPress Trac]

#39309: Secure WordPress Against Infrastructure Attacks
------------------------------------------+-----------------------
 Reporter:  paragoninitiativeenterprises  |       Owner:  pento
     Type:  enhancement                   |      Status:  assigned
 Priority:  normal                        |   Milestone:  5.2
Component:  Upgrade/Install               |     Version:  4.8
 Severity:  critical                      |  Resolution:
 Keywords:  has-patch                     |     Focuses:
------------------------------------------+-----------------------

Comment (by dd32):

 Hey @paragoninitiativeenterprises

 I've been experimenting with some approaches for integrating signature
 verification
  - I've got a [https://github.com/dd32/wp-signed-updates/ demo plugin]
 which does signing/verification that I've been using to refamiliarise
 myself with it, there's a few basic integration tests that confirm signing
 works as intended.
  - I've got a [https://github.com/dd32/wordpress-
 develop/tree/feature/39309-signed-updates branch] which adds support to
 WordPress, based off of the above plugin, but not aligning 1:1. We should
 consider porting some of the tests from above over too.

 A few things I've noticed:
 I'm concerned about Memory Usage, with some plugins and core packages
 hitting 10+MB
  - `sodium_crypto_sign_verify_detached()` requires that the entire package
 is held within memory, due to the algorithm requirements that makes sense.
  - `Sodium_Compat`'s implementation of
 `sodium_crypto_sign_verify_detached()` requires twice the memory, so
 20+MB. Given it's being used for compat purposes, it seems highly likely
 that these will also be instances where less memory is going to be
 available (Even if it is only PHP 5.6+ if the PHP requirement bump goes
 through).

 I've instead looked into hashing the file and signing that hash via
 `sodium_crypto_sign_verify_detached()` instead
 - The above plugin/patch uses SHA384 via `hash_file()`, which appears to
 be the best hashing option available from your list and compiled into PHP.
 - I looked into using Blake2b as implemented as `generichash` in Sodium,
 unfortunately the `Sodium_Compat` implementation is incredibly slow in my
 testing (5+ minutes verses 0.2s on 10MB) which rules that out for now.
 - `SHA-512/256` and `SHA-512/224` are only available in PHP 7.1+ and
 didn't immediately appear to have a PHP 5.6 compatible option.
 Are there any other options which might be better suited here?

 Other Implementation Notes:
  - The signature is implemented as being provided in a HTTP Header (If
 server supports it) and also being available as a separate file for
 fallback in the cases where setting a HTTP Header isn't viable.
  - The implementation allows for multiple public keys AND multiple
 signatures to be presented/attempted, That's for a future use where we
 change the hashing, signing algorithm, or are transitioning between
 signing keys.
  - It's tied to WordPress.org domains where we could possibly route files,
 plugins can filter that and also register their own keys. It's reasonable
 to suggest that this shouldn't be filterable, but if code can filter it,
 it could re-reroute or alter signature verification anyway.
  - It's implemented in soft-fail mode currently, reporting failure reasons
 to WordPress.org for debug during development (Data is not yet collected).
 I would anticipate running in that mode for several months until no more
 failure reports happen or are mitigated.
  - I've chosen to base64 encode signatures and public keys, hex encoding
 is also an option, no particular reason.
  - I'm also looking at this from a WordPress.org-signing perspective,
 since the implementation affects both systems.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/39309#comment:56>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform