admin account exploit

[jeremyclark13]

It looks like milworm has an exploit for 2.6.1.
Link : ​http://www.milw0rm.com/exploits/6397

It looks like they can register an admin account then use the lost password function to have the password changed.

[Otto42]

Supporting info:
​http://www.suspekt.org/2008/08/18/mysql-and-sql-column-truncation-vulnerabilities/

Basic problem: mySQL will consider "admin" = "admin(55 spaces)x" because it doesn't do binary comparisons on the data when the column is a string type, so the spaces are truncated off (as is the x, due to the length limit on the column).

Looks like ALTER TABLE wp_users DROP INDEX user_login_key , ADD UNIQUE user_login_key ( user_login ) would prevent it, to me. With a unique index, the insert of the new "admin(spaces)x" user would fail because of the comparison as well. And the user_login name should be unique anyway.

[g30rg3x]

This problem was already addressed in changeset ​8748 (for 2.6.x) and in ​8704 (for trunk).

[Otto42]

Replying to g30rg3x:

This problem was already addressed in changeset ​8748 (for 2.6.x) and in ​8704 (for trunk).

Bah. I liked my solution better. ;)

However, that change is post-2.6.1, so the current latest released version is still vulnerable to this attack. 2.6.2 should get pushed out quickly because of this flaw, IMO.

[g30rg3x]

:P

2.6.2 should be released ASAP (IMHO), cause it not only address that bug, it also address ​this bug and unfortunately it was only matter of time before someone point out this flaws (before the release of 2.6.2) and releases his "exploits" to the public.

[mrmist]

+1 to having a unique index on the column anyway, although probably in conjunction with a user-side error when trying to add a non-unique name.

The "add user" page really should be picking up on and preventing it.