Open sesame! [WordPress 2.8.3 change password vulnerability]

Well that was fortuetous! I was trying to find details on why the Suhosin extension keeps segfaulting PHP 5.2.10, and somehow ended up at Milw0rm reading an article on PHP include security. It’s been a while since I’d read anything on the site so thought I’d have a gander at the list on the main page and low-and-behold a remote adminsitrator password exploit for WordPress 2.8.3 was there, and at the time of writing is two days old. The exploit is one of those really simple and effective ones, whereby passing an array instead of a string bypasses some conditional statements; the full article is here.

This is the kind of security failure that can really bite. It would be trivial to write a script to exploit en mass thousands of WordPress installations and then post spam messages; my only surprise is that after two days nobody has caught on. Well, maybe someone has caught on and my sites are far too small to be indexed, and hence were not afflicted. Having said that, Akismet catches about fifty spam comments a day so it is still a target, albeit small.

Needless to say, I’ve upgraded my WordPress installs. It has also forced me to think of tightening my database security. To date, I’ve never gotten more granular than assigning specific permissions to different tables, and even that is rare: usually I just assign blanket permissions for a database. Given that this exploit would have been stopped if the password column or the specific row for the administrator password was read-only, being a little more prudent in the future may be a smart idea. It doesn’t suggest that every row or column in a database has to be fine tuned, however protecting those critical records or fields that are easily targeted would likely pay off in the long term. MySQL does row and column level security… doesn’t it?

Another illustration of why defense-in-depth can save the day. Oh well, it looks like I’m tweaking my MySQL installation tomorrow. Having said that, I’m a little annoyed with whoever wrote that bit of PHP code in the first place. Personally, I’m no software engineering guru but checking types before comparison operators generally doesn’t escape me (no pun intended), and certainly within security critical code like password changing. The problem may be two fold: PHP allows the programmer to write sloppy code in the first place, there is no necessity to be particularly aware of changes of variable type; the other reason I surmise is that if someone has learnt programming using a strongly typed language like Pascal, ADA or the like then considering variable type is burnt into your brain. Even C forces you to think about it, although you are given a lot of latitude to screw things up. The combination of people who have either learnt to program using PHP or predominantly use PHP and the loose type checking in PHP has created a problem that will just keep recurring.

Is it possible to construct a nice little security utility that checks PHP code and gives output of the form: “transparent cast from array to string on line xxx, do you really want to do this”? Would anyone use it?

UPDATED 12th August 2009 @ 22.00pm: According to a notice on the WordPress site, here, the vulnerability causes a new password to be emailed to the account owner’s email… so isn’t as bad as I thought. Suppose it also pays not to write posts at four in the morning.

UPDATED 12th April 2010: Added [] extra meaning in title.

Leave a Reply

Your email address will not be published. Required fields are marked *