I must say that I find the paths of logic in the WordPress code to be hard to follow, and apparently the developers must feel the same since these kinds of vulnerabilites come up again and again.

I recently found the PHPrevent: PHP Security Project which implements a taint mode into PHP, similar to Perl. I think that’s an interesting idea that might help people with plugging these holes.

The $id thing in the promotion feature of WordPress was one of the SQL injections I disclosed to them. It allows registered users with atleast user_level 1 to set f.e. all users down to level 0 (as a DOS).

At the same point they also fixed a register_globals=On SQL injection, that I also disclosed to them. When the promotion direction was neither up nor down, it was possible for a user with user_level 1 to inject a complete SQL query, by simply setting the variable sql.

The thing in wp-setting.php is however a problem of remote code execution when register_globals is turned on. WordPress internally uses a bunch of filter hooks, that can be set by f.e. plugins etc…

Due to this not protected against register_globals at all, it was possible for an attacker to define from the outside, what actions of WordPress cause what PHP functions called. An exploit that uses this flaw to execute anything on WordPress < 1.5.2 (replacement-version) blogs was posted to public security sites 6 days before WordPress 1.5.2 was released. (About 8 hours after they had fixed it in their subversion tree).

And yeah, and unless written elsewhere: I am not the original finder of the last vulnerability. I was just the one who told them after the release, that their fix is easiyl bypassable.

The change in users.php was probably nothing then, considering that the piece of code I talk about isn’t executed unless you are logged in as an admin (or maybe just as a normal user, I’m not sure).

In any case: remember to upgrade any installation you might have.