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

Fri Sep 21 05:48:27 UTC 2018

#39309: Secure WordPress Against Infrastructure Attacks
------------------------------------------+-----------------------------
 Reporter:  paragoninitiativeenterprises  |       Owner:  (none)
     Type:  enhancement                   |      Status:  reopened
 Priority:  normal                        |   Milestone:  Future Release
Component:  Upgrade/Install               |     Version:  4.8
 Severity:  critical                      |  Resolution:
 Keywords:  has-patch                     |     Focuses:
------------------------------------------+-----------------------------

Comment (by paragoninitiativeenterprises):

 We released
 [https://github.com/paragonie/sodium_compat/releases/tag/v1.6.6
 sodium_compat v1.6.6] tonight, which introduced a ''significant'' speedup
 on 32-bit platforms (i.e. `PHP_INT_SIZE === 4`).

 I believe it is now reasonably practical to consider Ed25519 signature
 verification on future WordPress updates.

 Questions:

 1. What are the specific infrastructure blockers on the WordPress.org side
 that need to be resolved before my patches can be considered for merging?
    * To be preemptive, demanding HSM support is
 [https://www.psychologytoday.com/us/blog/happiness-in-world/201106/why-
 perfect-is-the-enemy-good making perfect the enemy of good]. But even if
 that demand is still on the table, YubiHSM supports Ed25519 so this
 problem is solved. Surely the companies that depend on WordPress can swing
 for one?
 2. What additional code changes need to be made to accommodate this patch?
    * e.g. making sure update servers push the Ed25519 header alongside the
 update file
 3. What are the social (and/or office-political) objections to this
 change?

 In the event of a security concern, I'd like to remind everyone that
 libsodium is in the PHP standard library as of 7.2, so any concerns over
 the security of Ed25519 need to be raised in a lot of places (and probably
 published on the IACR if you've discovered a new attack).

 ------

 As far as code audits go, I'm not sure what to suggest.

 The quotes I received ranged from $2k to $4k per person-day, for a minimum
 of two weeks. One firm issued a flat rate quote in the $20-30k range. This
 isn't the sort of thing you can solve with Fiverr.

 But more pertinently:

 * None of the firms who specialize in cryptography (save ours) also
 specializes in PHP.
 * None of the software security firms specializing in PHP that we're aware
 of have cryptography experts on staff.

 A first-party cryptography audit is
 [https://www.schneier.com/blog/archives/2011/04/schneiers_law.html
 useless]; only through third party verification can we hope to gain
 confidence that a specific implementation is secure.

 This presents a unique challenge for us: Who else has the prerequisite
 experience and specialized domain knowledge to check our work?
 Furthermore, an audit of sodium_compat would also require auditing the
 various PHP versions that WordPress supports. To wit:

 * PHP 5.2.4
 * PHP 5.2.5
 * PHP 5.2.6
 * PHP 5.2.7
 * PHP 5.2.8
 * PHP 5.2.9
 * PHP 5.2.10
 * PHP 5.2.11
 * PHP 5.2.12
 * PHP 5.2.13
 * PHP 5.2.14
 * PHP 5.2.15
 * PHP 5.2.16
 * PHP 5.3.0
 * PHP 5.3.1
 * PHP 5.3.2
 * PHP 5.3.3
 * PHP 5.3.4
 * PHP 5.3.5
 * PHP 5.3.6
 * PHP 5.3.7
 * PHP 5.3.8
 * PHP 5.3.9
 * PHP 5.3.10
 * PHP 5.3.11
 * PHP 5.3.12
 * PHP 5.3.13
 * PHP 5.3.14
 * PHP 5.3.15
 * PHP 5.3.16
 * PHP 5.3.17
 * PHP 5.3.18
 * PHP 5.3.19
 * PHP 5.3.20
 * PHP 5.3.21
 * PHP 5.3.22
 * PHP 5.3.23
 * PHP 5.3.24
 * PHP 5.3.25
 * PHP 5.3.26
 * PHP 5.3.27
 * PHP 5.3.28
 * PHP 5.3.29
 * PHP 5.4.0
 * PHP 5.4.1
 * PHP 5.4.2
 * PHP 5.4.3
 * PHP 5.4.4
 * PHP 5.4.5
 * PHP 5.4.6
 * PHP 5.4.7
 * PHP 5.4.8
 * PHP 5.4.9
 * PHP 5.4.10
 * PHP 5.4.11
 * PHP 5.4.12
 * PHP 5.4.13
 * PHP 5.4.14
 * PHP 5.4.15
 * PHP 5.4.16
 * PHP 5.4.17
 * PHP 5.4.18
 * PHP 5.4.19
 * PHP 5.4.20
 * PHP 5.4.21
 * PHP 5.4.22
 * PHP 5.4.23
 * PHP 5.4.24
 * PHP 5.4.25
 * PHP 5.4.26
 * PHP 5.4.27
 * PHP 5.4.28
 * PHP 5.4.29
 * PHP 5.4.30
 * PHP 5.4.31
 * PHP 5.5.0
 * PHP 5.5.1
 * PHP 5.5.2
 * PHP 5.5.3
 * PHP 5.5.4
 * PHP 5.5.5
 * PHP 5.5.6
 * PHP 5.5.7
 * PHP 5.5.8
 * PHP 5.5.9
 * PHP 5.5.10
 * PHP 5.5.11
 * PHP 5.5.12
 * PHP 5.5.13
 * PHP 5.5.14
 * PHP 5.5.15
 * PHP 5.5.16
 * PHP 5.5.17
 * PHP 5.5.18
 * PHP 5.5.19
 * PHP 5.5.20
 * PHP 5.5.21
 * PHP 5.5.22
 * PHP 5.5.23
 * PHP 5.5.24
 * PHP 5.5.25
 * PHP 5.5.26
 * PHP 5.5.27
 * PHP 5.5.28
 * PHP 5.5.29
 * PHP 5.5.30
 * PHP 5.5.31
 * PHP 5.5.32
 * PHP 5.5.33
 * PHP 5.5.34
 * PHP 5.5.35
 * PHP 5.5.36
 * PHP 5.5.37
 * PHP 5.5.38

 ... and those are just the [https://secure.php.net/supported-versions.php
 versions of PHP that are no longer supported by the PHP team]!

 So if "we need an audit" is the big blocker issue, as Matt Mullenweg as
 expressed in the past, then it bears emphasizing the level of effort being
 demanded here.

 An auditor would be required to:

 1. Verify that there are no security bugs in sodium_compat itself. This is
 the easy part.
 2. Verify that there are no security-affecting side-channel attacks made
 possible by the PHP interpreter (and/or OpCache).
 3. Verify that any null findings in step 2 hold for every PHP version I
 listed above, and also for all the versions that are still supported by
 the developers of PHP.

 A team of three security experts (consisting of at least one
 cryptographer) would likely burn months of their lives on making sure this
 is done right. And that's just for one audit; a single data point.

 Speaking of points, I hope mine is clear: Please tell me what the specific
 obstacles are to getting this merged, and I will do what I can to solve
 them.

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