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

[WordPress Trac]

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

Comment (by paragoninitiativeenterprises):

 @pento:

 > Without trying to turn this into a bikeshedding ticket, are there
 options available that are already built?

 There aren't any in the PHP ecosystem, outside of PIE's work. (See also:
 [https://github.com/paragonie/airship/blob/master/src/Engine/Keyggdrasil.php
 Airship], which was designed from the ground up to be automatically
 updated, securely.)

 Outside of PHP, there is [https://theupdateframework.github.io/ The Update
 Framework] which is chiefly concerned with solving the problem that
 WordPress has already solved in this ticket. So that's not very helpful
 either.

 Mozilla uses a system they call
 [https://wiki.mozilla.org/Security/Binary_Transparency Binary
 Transparency] which piggybacks on Certificate Transparency to sign new
 releases. It's a clever use of existing technology, but going that route
 would probably require a partnership with the ISRG (a.k.a. Let's Encrypt).

 Ultimately, secure code delivery is as much an important problem as it is
 a woefully neglected one. And none of the solutions we're aware of have
 attempted to tackle it at the ecosystem level before (i.e. to enable
 individual developers to manage their own keys and sign their own updates,
 rather than just a central body).

 We're breaking new ground here, and it's important to get it right
 (especially if other projects look to WordPress for inspiration or
 guidance on how to deploy such a system at scale).

 @withinboredom:

 > Verification of these blocks takes some time. Having lots of them
 results in an indeterminate amount of time to do so. This could mean that
 a DOS is as simple as doing many releases.

 ...

 > Another DOS attack vector (that's used in the wild with GPG, I can't
 recall the name of it right now), is to simply sign a key with hundreds,
 or even thousands of other randomly generated keys. Verifying the
 signatures takes time and can even keep a very powerful computer busy for
 quite a while (months?).

 In the scheme I proposed, the only system that can write to the ledger is
 the update server. We can throttle writes to the ledger at that layer if
 someone is trying to abuse the system.

 Additionally, Ed25519 signature verification is very fast (with ext/sodium
 installed, which I certainly hope it *would* be on the WordPress backend
 infra). You can squeeze thousands of such verifications in a second. This
 isn't anything like a blockchain with a 7 tx/s bottleneck.

 If Chronicle is selected as the cryptographic ledger, it's worth noting
 that Chronicle uses a hash chain data structure rather than a Merkle tree.
 The main implication here is: Writes are faster and it uses less memory.
 Since writes are centralized (but verification is decentralized), a hash
 chain is appropriate. (You'd want a Merkle tree in a decentralized
 publishing.)

 -----

 To move forward, we just need answers to the following questions:

 1. Does WordPress want a solution sooner-than-later? (This answer will
 dictate Paragon's resource allocation into this initiative.)
 2. How much third party review will be satisfactory for any
 designs/implementations we propose?
 3. Bonus: Would any of the companies that rely on WordPress be willing to
 hire auditors to provide additional third party review if need be?

 This might be a good topic to ask during the weekly dev meeting on
 Wednesday, if you'd like to wait until then before answering.

 I've already pinged a couple colleagues for their feedback on this design.
 I hope if they see any sources of concern with Gossamer's design, they'll
 chime in directly. If they opt to send me any feedback privately, I'll
 share it here as soon as I've received and understood their issues.
 (Transparency is vital for these sorts of designs.)

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