WordPress insecurity

WordPress logo Another computer related thing needing attention when I got home was [WordPress][]… version 1.5.2 has just been released to fix yet another security hole, although their announcement has no specifics (as usual).

They write “We’re happy to announce that a new version of WordPress is now available for download.” How can they be happy that a security hole has been found in their “extremely stable 1.5 series” once again?! They have released version 1.5.1 (May 9th, renamed to version 1.5.1.1), 1.5.1.2 (May 27th), 1.5.1.3 (June 29th), and now 1.5.2 (August 14th) in response to security holes being found.

I think that’s a bit too much for me to call this think “extremely stable” (I obviously believe that security is an important feature of a “stable” application.) It’s good that they react to the security holes and they try to fix them fast, but I don’t like the way they just write that they have “addressed all the security issues that have been circulating the past few days”. Some questions immediately spring to mind:

  • How many security holes were there?

  • What was the nature of the hole(s)?

    • Could they “just” change the database? If so, which parts of it?

    • Could they upload files to my server? If so, could they overwrite my previous files?

  • How can I see in my log files if I’ve been exploited?

Instead of being vague I would like to see specific information about the problems. Browsing through the changesets doesn’t really help either, for the WordPress developers seems to make a point out of obscuring their fixes.

Take this changeset (revision 2779) for example, which committed on the 1.5 branch two days before the announcement of version 1.5.2 with the innocent message of “Move above”. Some lines are really moved up a little further in wp-settings.php — they deal with undoing the work of the infamous register_globals setting in PHP. But the lines are not just moved, an extra check is added to ensure that the variable $table_prefix isn’t unset. Why? Is this one of the security problems they’re talking about? Given the extreme lack of comments we can only guess…

Or maybe the fix was smugled in with revision 2780, together with fixes for seven small bugs and feature requests? The change to wp-admin/users.php in that changeset involve replacing

$id = $_GET['id'];

into

$id = (int) $_GET['id'];

and to my eyes this could be the fix they’re talking about. Especially since $id is used in an SQL query next… So if this analysis is correct then WordPress 1.5.2 was sent out to guard against an SQL injection attack. If anybody else has information about this then I would of course be interested!

7 Comments

  1. Martin Geisler:

    Well… reading through some more of my mail I found a discussion in the WordPress forums about the problem. So it appears that the problem was caused by wp-settings.php and fixed in revision 2779.

    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.

  2. Janus Tøndering:

    You can find detailed information about the <=1.5.1.2 vulnerabilities at http://seclists.org/lists/bugtraq/2005/Jun/0280.html.

  3. Stefan:

    Martin, your analysis is not bad.

    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.

  4. Martin Geisler:

    Damn… that is dangerous stuff! Thanks for the link!

  5. Martin Geisler:

    Thanks a lot for the detailed explaination — I never expected anybody to actually reply to my rant, and certainly not with such detail :-)

    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.

  6. jameswillisisthebest:

    This is my first post
    just saying HI

  7. Sherif Elsisi:

    I know it has been a while, but now even with wordpress versions of higher than 2, I got SQL injection attacks. Attackers on my sites targeted the wp_options table. One great solution I found on blogsecurity.net, was to always make sure to change the table prefix when installing wordpress.

Leave a comment