[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:
------------------------------------------+-----------------------------

Comment (by paragoninitiativeenterprises):

 > I don't think shipping a PHP-based SHA512 implementation is worth
 anyones time here.

 Given that `hash()` is supposed to be in PHP 5.1.2 and newer, anyone using
 something as old as 5.2.4 should have still it:
 http://php.net/manual/en/function.hash.php

 Anyone who claims not to is either lying about their actual PHP version or
 running a dangerous configuration, probably by having compiled it
 themselves once upon a time.

 Either way, I'd agree with not supporting systems without ext/hash.

 > All signatures should be transparent to a user, a typical user should
 never be prompted to enter hashes, nor see them.

 Indeed, the only person who will **ever** need to do anything is the
 release managers.

 > 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.

 Yep. That's why the patch has a hard-coded Ed25519 public key (the exact
 keypair given is in my comment above).

 > It should also be expected that core would have a minimum of 2 valid
 signing keys authorised, to allow for secure revocation and replacement.

 This is similar to Airship's requirements, where everyone has at least two
 keys: One master key, and one signing key. The master key can revoke or
 mint new (master, signing) keys. The signing keys are the ones actually
 used for package signing. (This is true for Paragon as it is for anyone
 who builds an Airship extension.)

 This is a more robust model should the signing key ever be compromised.

 > 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.

 Please do.

 > 39309.2.patch​ doesn't actually use the libsodium extension, correct?
 due to it's reliance upon ParagonIE_Sodium_Compat::*()

 It uses sodium_compat. If ext/libsodium is installed, sodium_compat will
 just kick off to the extension. If it's not installed, then sodium_compat
 uses the pure-PHP implemenation. This is a reasonable trade-off:

 * If you can install PHP extensions from PECL, you get greater performance
 and less risk of side-channels introduced by the PHP interpreter
 * If you cannot install PHP extensions from PECL, you can still verify
 signatures etc.

 > @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?

 Strictly speaking, it is possible to isolate Ed25519 and its dependencies.

 However, that's a hack job that I don't think anyone is going to want to
 perform every time we release an update. Given the delicate nature of
 security code, I wouldn't recommend doing so. Additionally, if someone
 wanted to use sodium_compat in a WordPress project (e.g. an extension that
 communicates via the Noise protocol framework, using our ChaCha20Poly1305
 implementation) and you only pulled in part of it, they'd probably have a
 bad time.

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