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

[WordPress Trac]

#39309: Secure WordPress Against Infrastructure Attacks
------------------------------------------+-----------------------------
 Reporter:  paragoninitiativeenterprises  |       Owner:
     Type:  enhancement                   |      Status:  new
 Priority:  normal                        |   Milestone:  Future Release
Component:  Upgrade/Install               |     Version:  trunk
 Severity:  normal                        |  Resolution:
 Keywords:  has-patch                     |     Focuses:
------------------------------------------+-----------------------------
Changes (by dd32):

 * milestone:  Awaiting Review => Future Release


Comment:

 I don't have time to delve deeply into this right now, however, a few very
 rough notes:

  * Due to our old PHP support, sometimes `ext/hash` isn't available.
 #29518  We may be able to require the extension, or simply skip signature
 verification for those cases. I don't think shipping a PHP-based SHA512
 implementation is worth anyones time here.
  * Once again, `ext/spl` can be disabled under PHP 5.2. So no form of
 autoloading is possible on those systems.
  * Based on the above, supporting back as far as possible is good, but
 IMHO PHP 5.3+ is acceptable. PHP 5.2 support here isn't critical. PHP 5.3
 may still be able to disable `ext/hash` though, but once again, I'm fine
 not supporting that.

 Testing against `https://wordpress.org/wordpress-latest.zip` with
 signature verification based on  [attachment:39309.2.patch]  & comment 5
 above
  * Under PHP 7.0 local VM performance was ~240ms per sign, ~255ms per
 verify.
  * Under PHP 5.3.3 local VM performance was ~380ms per sign, ~330ms per
 verify.
   * PHP 5.3.3 with CPU throttled to 20%, performance suffered obviously
 with ~830ms per sign, ~950ms per verify.

 Not super-fast, but not out of the question. I'm not sure why signing was
 slower than verifying in the initial PHP 5.3.3 run, I've run it over 50
 iterations twice on each setup with similar results.

  * It should be expected that signature verification may take up to a
 second in the wild, hosts are likely going to be under increased load
 during updates and that will affect signature time. Not all WordPress
 sites are hosted with adequate hardware resources.
  * It should also be expected that core would have a minimum of 2 valid
 signing keys authorised, to allow for secure revocation and replacement.
   * For example; primary and secondary backup, OR one primary for Core,
 one primary for plugins/themes/translations/etc, single secondary to
 authorise key replacements, OR something else that made sense.
   * If multiple "primary" keys are possible, a way to differentiate which
 keys are options for which packages would be needed.
   * Secondary keys would add a overhead for failed verifications, but
 failed signature verification appears to be rather fast, as it aborts much
 earlier.
   * ''This does not affect initial implementation of patches, nor is an
 immediate blocker to be solved, it would require discussion on the w.org
 systems side to determine what route we would take here.''

 A few more random thoughts and notes:
  * All signatures should be transparent to a user, a typical user should
 never be prompted to enter hashes, nor see them.
  * Individual w.org authors having their own keys/etc, should be kept out
 of scope for now and focused on later, don't complicate matters further
 than needed for now, focus on the W.org => W link.
  * Focusing on `Ed25519` seems fine to me, however, I've reached out to a
 few others to ask if anyone has other preferences we should look at here.
  * [attachment:39309.2.patch] doesn't actually use the libsodium
 extension, correct? due to it's reliance upon
 `ParagonIE_Sodium_Compat::*()`
  * @paragoninitiativeenterprises I assume it wouldn't be possible for us
 to only ship the the `Ed25519` crypto (&dependancies) with WordPress, we'd
 have to pull the full libsodium compat in, correct?

 Finally; Marking this as `Future Release` as it's accepted we'll add
 something here, but no firm timeline for completion at this point in time.

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