WordPress issues critical security fixes, closing remote anonymous compromise bug and more

WordPress, the internet’s most widely-used web publishing and blogging system, has just published a critical security release.

Amongst the fixes is a bug noted as “a critical cross-site scripting vulnerability [that] could enable anonymous users to compromise a site,” which is critical indeed.

Fortunately, however, that bug doesn’t apply to WordPress 4, which came out in September 2014.

So, if you’ve already upgraded your WordPress installation, you still get an update (to 4.0.1) but remote anonymous compromise isn’t one of the holes patched.

If you haven’t upgraded to WordPress 4 yet, you really should.

As WordPress explains rather bluntly in its Release Archive, where you can get every build back to 0.71-gold from June 2003, “none of these are safe to use, except the latest in the 4.0 series, which is actively maintained.”

Usage figures, however, suggest that an absolute majority of WordPress installations, just a shade over 55%, are still on Version 3.

So, WordPress Versions 3.9, 3.8 and 3.7 are still getting updates, qualifying them for “passive maintenance,” even if they aren’t actively being developed any more.

As well as the remote anonymous compromise bug in Version 3, there are eight patches to improve security in Versions 3 and 4.

Dangers of backward compatibility

The big lesson amongst them, in our opinion, is:

An extremely unlikely hash collision could allow a user’s account to be compromised, that also required that they haven’t logged in since 2008 (I wish I were kidding).

As far as we can tell, this fault was in password-checking code that allows users to login even if they have old-style MD5 passwords:

In the pre-2008 era, the WordPress login process simply checked your password against a plain MD5 hash stored in the login database.

That’s not good enough today (indeed, it wasn’t good enough in 1998, let alone 2008, but that’s another story), because it makes offline cracking of a stolen database much too easy.

A modern-day cracker can easily try billions of password guesses every second.

Also, a straight unsalted hash means that everyone with the same password has the same hash, so any passwords you cracked before are cracked forever.

With unsalted MD5 hashes, password123 always comes out as 482c811d­a5d5b4bc­6d497ffa­98491e38.

Sadly, even the updated WordPress 4.0.1 will still let you login with an old-school MD5 hash, if that’s what’s stored in the user database.

Granted, the login code immediately re-hashes your password with a more secure algorithm, and overwrites the stored value for next time.

But with MD5 passwords having been retired from WordPress so long ago – not that long, in fact, after Microsoft’s first official retirement notice for Windows XP – it’s probably time for WordPress to disavow MD5-hashed passwords altogether, and even to auto-delete accounts that haven’t been used since the MD5-only password era.

Limited password length

Another intriguing fix in this update is to impose a maximum password length for login attempts.

Regular readers will know that we’re inclined to get a little hot under the collar about limits on password length, but this one isn’t a Google-like upper limit of 17 characters, as in Android, or a 16-character Microsoft limit, as in Outlook.com.

The limit is now set to 4096 characters, on the grounds that validating the hash of an extremely long password is harder on your server’s CPU than a password of a reasonable length, simply because it requires more loops through the hashing algorithm.

So the 4096-character limit still allows absurdly long passwords in real life, without allowing malcontents to submit megabytes of password data at every login attempt, potentially creating millions of times more server load than any legitimate login.

Ironically, if you really do have a 4097-byte password, you’re sunk, because WordPress will no longer accept it.

You’ll have to do a password reset instead, a WordPress feature that also received a security patch in this latest release, and pick a shorter password.

The bottom line

  • If you’re running your own WordPress and you have typically found that you fall behind on patches (we admit they can be a chore), consider turning on WordPress’s automatic updates.
  • If you haven’t upgraded to the Version 4 series of WordPress yet, consider doing so. Older versions are not being actively maintained, and so may make easier pickings for crooks.
  • If you have WordPress users from before 2008 who haven’t logged in for all that time, consider removing them altogether and getting rid of any old-style password hashes.