WordPress Exploit Allows Admin Password Reset

Multiple readers have sent word of a vulnerability in WordPress 2.8.3 which allows anyone to lock an admin out of his or her account by resetting the password. "The bug ... is trivial to exploit remotely using nothing more than a web browser and a specially manipulated link. Typically, requests to reset a password are handled using a registered email address. Using the special URL, the old password is removed and a new one generated in its place with no confirmation required." An alert on the Full Disclosure mailing list detailed the vulnerability, and WordPress quickly rolled out version 2.8.4 to address the issue.

Clarification

[Jugalator]

For those who don't RTFA, this doesn't give the attacker access to the new, reset, password. That requires access to the admin's mailbox as well. So the link saying "lock an admin out" is a bit, well, not completely true. It could be true if his/her inbox is hacked, but not otherwise.

WordPress is Awesome

[mrspecialhead]

*opens dashboard, presses "Upgrade to 2.8.4" button*

Fixed. :D

Re:Clarification

[makomk]

RTFA? Did you RTFSummary? The point is that the password is reset but the reset doesn't get sent to the admin email as per usual.

Except that's not actually what it says, and even if it was TFA states otherwise:

As a result, the first account without a key in the database (usually the admin account) would have its password reset and a new password would be emailed to the account owner.

The e-mail that doesn't get sent is the one asking the user to confirm they want to reset their password, since that step is bypassed by the exploit.

Re:The great fallacy of root passwords

[TheRaven64]

The kernel does not run at the same privilege level as root. Root is a user which the kernel allows to access (some) privileged services. Root programs run in ring 3 (on x86, unprivileged mode on other platforms), while the kernel runs in ring 0 (or privileged mode on non-x86 platforms). The kernel can access physical hardware directly. The root user can not, they can only request that the kernel access it on their behalf. On some UNIX systems there is a device node which allows a sufficiently-privileged user to map arbitrary memory pages, however this is not something that root can do without the kernel exposing this device and without the kernel deciding which userspace processes are allowed to do so. A program running as root can not, for example, write to a device or alter the page tables without the kernel mediating this.

A privilege escalation vulnerability in the kernel may or may not be related to the root user. Often they are not, for example the recent SCTP vulnerability in Linux permitted arbitrary code to be run in kernel space, meaning that the root user was completely irrelevant. Other privilege escalation vulnerabilities only allow you to run your code as if it were run by root, in which case systems like SELinux or system immutable flags in the filesystem may still prevent you from doing things you want to.

Re:Clarification

[Tumbleweed]

> Using the special URL, the old password is removed and a new one generated in its place with no confirmation required.

While you're right in saying the attacker can't access the admin's account, the admin themselves also can't access it, because their password has already been reset to something else, and they'll have to get the new one. It seems more like a minor inconvenience to me, then a massive bug which will end the world, but still a flaw.

The admin still gets the password change notification, though, so the net effect is that someone is changing their password for them, notifying them of that, yet the attacker still can't get access to the admin login info unless they have access to the admin's email account. The admin can simply check their email for the new password, though, so they're not really locked out. Annoying, yes, but a pretty minor issue, and it's already been fixed.

PHP is to blame

[sverrehu]

It appears that PHP, upon seeing an incoming parameter with a name that ends in [something] (where something may be empty), automatically turns that variable into an array.

How many of you PHP developers out there knew that? I didn't. And I had to dig quite a bit to find a reference to this behaviour in the docs.

So, incoming stuff from the URL or the POST data are no longer strings all the time. Can they magically become other things than strings and arrays as well? Maybe not now, but what if some PHP developer thinks up another "nifty" feature _after_ I read the docs; how then am I supposed to protect my application in the future? Do I need to re-read the docs every time I upgrade PHP?

And is there a way to turn this "we know better than you what you need"-behaviour off?

I'm sick of seing framework developers add "nifty" features that you have to know about in order to write secure code. It's not only PHP, but also several highly popular Java frameworks that I work with these days. Some of them make it quite easy to write to object fields that are normally out of reach of the input fields in a form.

I want a framework that makes it impossible to make mistakes, and where you have to _enable_ potentially dangerous features when you _know_ you need them, rather than _disable_ potentially dangerous features most people don't know about (or use).

Re:Don't get it

[MtlDty]

There is a discussion about the vulnerability on StackOverflow [stackoverflow.com]

Re:Clarification

[stuckinphp]

Hardly specially crafted.. Here you go script kiddies, have fun while true; do lynx -dump http://domain_name.tld/wp-login.php?action=rp&key%5B%5D= [domainname.tld]; done &

Re:Stupidity

[Skadet]

Right, I wondered myself why there was no validate_key_is_valid() function, or even a simple cast for that matter. $key = (string)$key.

On the other hand, this isn't exactly PHP's fault (or MySQL's, for that matter). The query:

$user = $wpdb->get_row($wpdb->prepare("SELECT * FROM $wpdb->users WHERE user_activation_key = %s", $key));

They're selecting a row (the user) by a column (user_activation_key) that can be blank. Not NULL but literally an empty string. Bad.