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

[WordPress Trac]

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

Comment (by dd32):

 Thanks @paragoninitiativeenterprises!

 Replying to [comment:57 paragoninitiativeenterprises]:
 > Using `hash_file()` makes a lot of sense for keeping memory usage low.
 We wrote `ParagonIE_Sodium_File` to accomplish the same overall goal, but
 it's not foolproof.

 Glad I'm not totally off-base by suggesting it be used here then :) I
 can't imagine hosts will want to see the auto-update processes use
 significantly more memory either

 > Additionally, SHA384 is the best possible hash function for PHP <7.1
 support. (Composer uses this hash function too.) If anyone is concerned
 about SHA384 being used in other protocols, adding domain separation (as
 simple as using `hash_hmac_file()` with the HMAC key being a constant
 specific to WordPress that bears no secrecy requirements) would ensure
 that the hashes used in the file verification are distinct to WordPress.

 I hadn't considered the option of using hmac to have WordPress-specific
 hashes, it would certainly make sense if it adds any real additional
 difficulty in theoretical attacks.

 For others, I went and looked up the
 [https://github.com/composer/composer/blob/522ea033a3c6e72d72954f7cd019a3b75e28f391/src/Composer/Command/SelfUpdateCommand.php#L222-L233
 Composer implementation] which uses `openssl_verify()` and `sha384` as the
 `$algo`.

 > Overall, I think your patch makes sense and the main operational
 overhead remaining would be to generate/manage the Ed25519 keys on the
 WP.org side.

 Great to hear, thank you!
 The WordPress.org side is going to require much more additional work
 obviously, but should be operational soon for testing.

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