Scott Yang's Playground

Spotted from the WordPress “Dashboard” that WordPress 1.5.1.3 has just been released with a security fix on “xmlrpc.php“, the code that handles XML-RPC requests so you can manage your blogs using tools like w.bloggar and ecto.

Currently I am managing almost 20 WordPress 1.5 installations on FOCUSer.net (still having around 6 stubborn users that are still on MovableType 2.6), and I rely on Gentoo portage to provide ebuilds for web applications like WordPress. While the ebuild will probably not be available for another week, I decided to download the latest Strayhorn to check out the “security fix”, and how I can apply that to my existing installations if it is indeed severe.

It appears the latest xmlrpc.php includes an escape() function that adds MySQL’s proprietary SQL escaping sequence (via PHP function addslashes()) to ALL data received from XML-RPC. Aarrgghh!!! It is just so wrong! This WordPress thing keeps on giving me grief on how backslashes are handled, because like many early PHP applications that were made for nothing but MySQL, it adds backslashes when data is received (or decoded from XML-RPC package in this case)!

First of all, backslashes are bad. Anyone who has little knowledge of SQL should know that you escape a single quote character in SQL by adding another single quote character. Why use MySQL’s proprietary way when the standard SQL character escape works in MySQL too? Well, you still need to use a backslash to escape another backslash in MySQL, but that is due to MySQL’s own incompatibility with the standard.

But most importantly, if adding a backslash is there to defend against potential SQL injection, why not escape the data when the SQL is constructed, instead of when the data is received? This has potential to break a lot of things, where unaltered values are expected, including all the filters implemented by the plugins, etc.

For example, if your password contains backslash or single quote character – you will not even be able to log in, as md5 in the database will be different from the md5 from the input with special characters escaped. There are other backslash woes that each developer has to find his/her own way to work around.

While it claims to be fast and efficient, browsing through WordPress’ code brings me sore eyes sometimes. Meanwhile, I’ll just shut my eyes and use it, cross my finger and hope nothing bad might happen.

Update 8:45am: Security analysis done by GulfTech’s James Bercegay. Looks like an upgrade is inevitable. Maybe I will do my own ebuild first.

Update 10:30am: It appears Drupal has also announced a security update to release 4.6.2 and 4.5.4, due to issues with 3rd party XML-RPC library and input filters. However, it not only provides tarballs for download, it also releases patches to individual files and clear descriptions on what have been fixed, so you can check the differences yourself, and patch them accordingly.

Why doesn’t WordPress provide patches? I cannot even find tarballs or zippies of older releases on the WordPress website so I can figure out what have actually been changed! I guess it might be possible with the Subversion access. Hmm…

Update 10:47am: AAARGH!! I have just been bitten by that nasty NASTY backslashes again, after I patched xmlrpc.php manually. Now all my posts have backslashes added to single and double quotes, when sent via XML-RPC. Damn!! Let’s wait for WordPress 1.5.1.4.