WordPress insecurity
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!