WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

#29518 closed defect (bug) (fixed)

Fatal error in WP_Session_Tokens::hash_token()

Reported by: SergeyBiryukov Owned by:
Milestone: 4.0.1 Priority: low
Severity: major Version: 4.0
Component: Security Keywords: has-patch commit fixed-major
Focuses: Cc:

Description

Seeing some reports on support forums with the update to 4.0:

Fatal error: Call to undefined function hash() in wp-includes/session.php on line 64

Apparently Hash extension can be disabled.

Attachments (3)

29518.diff (1.6 KB) - added by nacin 3 years ago.
29518.2.diff (1.6 KB) - added by voldemortensen 3 years ago.
29518.3.diff (1.8 KB) - added by nacin 3 years ago.

Download all attachments as: .zip

Change History (15)

#1 @nacin
3 years ago

  • Milestone changed from Awaiting Review to 4.0.1

Oh dammit, we knew this and have been accounting for hash_hmac() for years.

Luckily last time we sampled it, it was like 0.12% or something crazy small, but that's still tens of thousands of sites.

@nacin
3 years ago

#2 @nacin
3 years ago

29518.diff falls back to sha1() if ext/hash is disabled.

For sites that have ext/hash currently:

  • No change. Sessions and cookies generated in 4.0 will work after update to 4.0.1.

For sites that don't have ext/hash:

  • No change from 3.9, and sessions simply use sha1.

For sites that loose ext/hash:

  • Their sessions and cookies will become invalidated. Also, WTF?

For sites that already updated to 4.0 and are issuing fatal errors:

  • Cron won't run any authentication functions, which means an automatic update can rescue these sites. This is pretty meaningless as it doesn't affect many people, but still — FTW. It also means we don't need to rush a 4.0.1 for this, which I loathe to do anyway.

For now, the support forums recommendation should be to:

  • Change sha256 to sha1 wherever it appears in pluggable.php (twice)
  • Change return hash( 'sha256', $token ); in session.php to return sha1( $token );
  • Update to 4.0.1 when it comes out (if it isn't automatic for them) to get the "proper" changs/

(function_exists( 'hash' ) ? 'sha256' : 'sha1' looks really weird and will need a code comment.)

#3 @nacin
3 years ago

Thanks mdawaffe for talking this through with me. Together we came up with way more insane solutions that will never see the light of day.

#4 @voldemortensen
3 years ago

Added documentation.

@nacin
3 years ago

#5 @nacin
3 years ago

Ah, thanks. I ended up having somewhat clearer docs locally already. see 29518.3.diff.

#6 @obenland
3 years ago

  • Keywords has-patch added

#7 @DrewAPicture
3 years ago

The docs in 29518.3.diff should work. Might be worth adding a blank line above the commented block just so it doesn't get lost in a block of code.

#8 follow-up: @jorhett
3 years ago

I would highly recommend that you push out an immediate fix to sample for whether hash works by running a quick test before doing the upgrade that you are very demandy about in the wordpress dashboard. Right now that's a button to kill your site, and for hosted blogs where the provider isn't quick to update packages they will be dead in the water.

easier than a complete fix -- just add a test for hash, and report back to the user instead of upgrading.

#9 in reply to: ↑ 8 @nacin
3 years ago

  • Component changed from General to Security
  • Keywords commit added
  • Priority changed from normal to low
  • Severity changed from normal to major

Replying to jorhett:

I would highly recommend that you push out an immediate fix to sample for whether hash works by running a quick test before doing the upgrade that you are very demandy about in the wordpress dashboard. Right now that's a button to kill your site, and for hosted blogs where the provider isn't quick to update packages they will be dead in the water.

easier than a complete fix -- just add a test for hash, and report back to the user instead of upgrading.

We'll definitely ship this in 4.0.1, expecting in the next 5 days I'd say. This affects very, very few sites. And honestly, a site breaking over this means they'll be forced to contact their host to get this resolved, which isn't the end of the world, because they're essentially dealing with a borked PHP install — and because their content is ultimately OK, and even the frontend of their site is ultimately OK, as would an auto update.

Going to go ahead and get this committed.

#10 @nacin
3 years ago

  • Keywords fixed-major added

#11 @SergeyBiryukov
3 years ago

[29751] missed the ticket.

#12 @nacin
3 years ago

  • Resolution set to fixed
  • Status changed from new to closed

So did [29761].

Note: See TracTickets for help on using tickets.