[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:  reopened
 Priority:  normal                        |   Milestone:  Future Release
Component:  Upgrade/Install               |     Version:  4.8
 Severity:  critical                      |  Resolution:
 Keywords:  has-patch                     |     Focuses:
------------------------------------------+-----------------------------

Comment (by paragoninitiativeenterprises):

 > Could you clarify in what way rolling back the currently non-functional
 and incomplete signature verification is reckless or negligent? It seems
 like the opposite is true: leaving testing code running in production
 after we've gotten results is lazy at best, and at worst could lead to
 significant maintenance issues that affect the critical auto update code
 paths.
 >
 > The test produced good results: we're able to sign packages in a way
 that all WordPress installs can verify,

 You answered your own question right there.

 The current implementation was ''temporarily'' non-enforced.

 A very minor patch needs to take it from ''non-enforced'' to ''enforced''.

 Making signatures required once we're sure that the verification works on
 all WordPress installs was the plan. Deviating from the plan to protect WP
 core updates is reckless and negligent. WP should stay the course.

 > @dd32 outlined 5 questions that need answering in his earlier comment,
 it seems like only number 3 can be delayed for now, as it mostly applies
 to signing plugin/theme updates. We still need solutions for all of the
 others, hence asking about Gossamer or alternative options.

 Here's the answer to your questions then:

 > 1. How do we mark a key as compromised and to no longer trust it?
 Current Answer: Release a new version of WordPress with a new alternate
 key - but what about those who don't update immediately? etc.

 People who don't update immediately aren't about to get their servers
 hosed by an auto-update. We're concerned chiefly with the security of
 auto-updates.

 What is the benefit of getting into a chicken-egg discussion here? The
 only way anything gets updated is if something gets updated. It's
 inescapable tautology.

 When Gossamer comes around, you can use the ledger mechanism to automate
 this out-of-band (i.e. always keep keys up to date, even if auto-updates
 are not installed).

 > 2. How do we rotate signing keys regularly keeping them with a limited
 timespan (Either X major WordPress releases, or X months/years) and having
 older WordPress installations still being able to trust a new key they've
 never seen?

 Scheduled key rotation in the current threat model is really security
 theater: Not doing it doesn't really hurt security, so long as the keys
 are managed properly. (If we were encrypting, that'd be a different
 story.)

 However, with Gossamer, you'll be able to revoke both malicious updates
 and public keys, and re-sign updates with new keys, and the keys will be
 automatically managed.

 > 3. Split signing into groups by type, ie. KeyA can sign Core releases
 only, a plugin signed by KeyA should be rejected.

 Punt.

 > 4. Only trust a signature from a key during it's lifespan - ie. If a key
 was valid for 2019-01-01 until 2019-06-01, a signature from that key on
 2019-09-01 shouldn't be valid. Oh, and it shouldn't be trusted if used for
 a signature after 2019-04-01 anymore as key was compromised or mishandled,
 but we still want to trust it for a signature from 2019-02-01.

 In the event of a key compromise:

 1. Publish a new verification key.
 2. Revoke the old verification key.
 3. Re-sign updates with the new key. (You can do this with a `for` loop.)

 You shouldn't build in crazy key rotation/lifetime schemes just for the
 sake of adding complexity and rituals to your life.

 Get an airgapped laptop with a YubiHSM and shuttle update files back and
 forth via DVD. (Optionally, you can also just manually transcribe the hex-
 encoded signature from the airgapped machine if you ''really'' want to
 save on DVDs.)

 If someone manages to compromise that setup, there was never any hope of
 WP defeating such an adversary to begin with. Making your lives miserable
 with key lifetimes won't help at all.

 > 5. How do we handle a maliciously signed package? Lets say that somehow
 someone gets a plugin package signed that should never have been signed
 (but the key isn't compromised) how do we prevent WordPress trusting that
 signature?

 Since plugin signing is Gossamer-specific, I hope you'll forgive me for
 punting on this.

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