It turns out, that the WordPress developers are not only slow in dealing with security holes, but totally irresponsible. It has come to my attention, that after I had disclosed to them, the obvious flaws in their security fix, they have silently replaced the release tarball of WordPress 1.5.2 with a fixed version at an unknown point in time during the last 2 days.

This means everyone who upgraded within the first day is most probably still vulnerable to the exploit. It is hard to guess how many people are affected, because the change of the tarball was performed without any notification of me or their users.

Update: from looking into the tarball timestamps, there is atleast a 9 hour time windows between both tarballs.

WordPress 1.5.2 has been released in response to the vulnerabilities. Unfortunately I had to tell the authors, that while they have properly fixed the SQL injection vulnerabilities which I had disclosed to them 26 days before, they have not properly fixed the remote code execution exploit.

With a trivial modification of the published exploit code, it will still work against WordPress 1.5.2. A fix for this has been commited 2 days ago, after I have sent them the necessary code.

Yeah and it is still reported that some "experts" claim this is a vulnerability in PHP and not in WordPress. When the pope visits cologne in 2 days I maybe should ask him how to deal with false prophets.

Update: The WordPress 1.5.2 tarball was silently replaced with a fixed one most probably 9 hours after the original release. So some who have updated are vulnerable and some not.

While some other people were busy discussing my motives and trying to covince others of my poor intentions, I was busy coordinating and preparing the release of another round of very serious XMLRPC vulnerabilities.

For more detailed information have a look at my advisories for PEAR XML_RPC and PHPXMLRPC.

Please upgrade your PEAR XML_RPC package as soon as possible or prepare to get owned by the next wave of XML_RPC exploits.

Updated packages for Drupal are already out and the other 21 affected applications will follow soon.

Tobias Schlitt gave me a link to the article 10 Tips That Every PHP Developer Should Know, Part 2 by Jeffery Vaska that recently appeared on phpbuilder.com. I was kinda shocked when I saw Tip #5, that describes howto deal with $_GET and $_POST. It mentions that a developer can use extract($_POST) to eliminate the need of assigning every single entry manually. It also mentions:

This is a matter of
convenience and is not always a best practice.

It completely fails to mention, that using extract() without using prefixes or the parameter EXTR_SKIP is usually a very big security hole, because it allows an external attacker to overwrite every variable, including the superglobals (unless you use the Hardening-Patch) and this can lead in many cases to SQL injection or even Remote Code Execution Vulnerabilities.

Gulftech has recently released an advisory for Squirrelmail, that describes exactly such an extract($_POST) flaw.

PHP applications have a very bad reputation when it comes to security issues. This seems unfair to everyone who actually writtes applications, that are not riddled with security holes, but it is quite understandable when you look how some vendors of prominent PHP applications deal with security problems in an irresponsible way.

One of the really bad examples is WordPress. They have a history of silently fixing vulnerabilities, waiting for ages until they release updated versions or not taking security holes seriously at all. Right at the moment, they know for 25 days about SQL injection vulnerabilities, that are exploitable by registered users. Furthermore they know about a WordPress Remote Code execution exploit in the wild, that was posted to public mailinglists 4 days ago and is widely used to exploit WordPress powered blogs.

During the last months, more and more self proclaimed PHP security experts have started spreading the FUD, that register_globals is evil and that you should always switch it off, when you develop or deploy an application. This has resulted in vendors ignoring or playing down vulnerabilities, which are only exploitable when register_globals is turned on. Even when their own hoster has this option activated, they claim the vulnerability is in PHP's register_globals and not in their application.

I strongly disagree with this kind of argumentation and because I see similiarities with the actions of a certain big software company I usually refer to it as Trustworthy PHPing.

Some weeks ago I have publicly disclosed 2 serious flaws in the PHP Security Guide of the PHP Security Consortium. The PHP community surely remembers the harsh response from the PHPSC leader in response to my publication. Until today he still claims, that the flaws only exist in my imagination (which is very strange because he has fixed them without proper credits) and that I haven't contacted 5 people among the consortium prior to my public disclosure.

Having learned from that experience I sent another flaw in their documentation directly to their official contact address, which is mentioned on their website. This time the flaw is located in their article about howto use Text_CAPTCHA.

The last 8 months of PHP history have been very terrifying. We have seen the rise of a Trustworthy PHPing campaign that even sucked in prominent members of the PHP community.

Today we are in a state that everyone who is able to create slides about input filtering is calling himself an international recognised PHP security expert.

Time has come to speak up and restore the balance.