(c) 2007. All rights reserved. The information contained in this newsletter, including any external links, is provided "AS IS," with no express or implied warranty, for informational purposes only. In some cases, copyright for material in this newsletter may be held by a party other than Qualys (as indicated herein) and permission to use such material must be requested from the copyright owner.
THE MONTH OF PHP BUGS
The month of March brought us the Month of PHP Bugs (MOPB), a full-disclosure campaign aimed at improving the overall security in the popular PHP application server platform. Like previous Month of Bugs initiatives (Month of Brower Bugs, Month of Apple Bugs), the MOPB coordinators are releasing a new bug every day for the entire month of March. One of the heavy-hitters behind MOPB is Stefan Esser, a former member of the PHP security response team. Stefan left the PHP security team due to a lack of momentum and various impasses in fixing the security bugs he found.
Politics aside, the MOPB effort has lived up to its promise. We've seen a new bug every day. But should PHP users be worried? At the middle of the month, we performed a 'mid-month' analysis of the bugs released so far. The analysis reviewed the overall impact of the bugs, their applicability to common deployments, and how they were being fixed by the PHP developers. The mid-month analysis is available at: http://portal.spidynamics.com/blogs/jeff/archive/2007/03/19/Month-of-PHP-Bugs_3A
00_-Mid_2D00_month-analysis.aspx
The biggest conclusion of the mid-month analysis was that typical users of the latest versions of PHP (5.2.1 and 4.4.5) only needed to worry about two bugs (MOPB #1 and #2). Those two bugs allow a remote attacker to perform a denial of service attack on the server. The remaining bugs were either fixed in the last released version of PHP, or require a local user/malicious PHP script executed on the system to exploit the bug. We also reviewed the bugs released after the mid-month analysis; our general conclusion is that the analysis results/conclusions are unaffected, as the newer bugs didn't change the overall dynamics of what was already released.
This brings up two important points: if you're not running the latest version of PHP (specifically 5.2.1 and 4.4.5), you should strongly investigate upgrading immediately. Many of the MOPB releases highlight bugs fixed in those releases, and some of them can be considered quite serious. Also, if you happen to be a web hosting provider or otherwise allow arbitrary users to upload and execute PHP scripts, you are in a very serious predicament: most of the MOPB bugs require local access to exploit, and once exploited, allow the arbitrary execution of code which can circumvent PHP's built-in safemode and other security restrictions. You may consider looking to Esser et. al.'s excellent and free Hardened-PHP or Suhosin patches to proactively add additional security constraints to PHP (and help mitigate many of the MOPB bugs in the process).
So far the PHP security team/developers have been making moderate fixes in response to the MOPB bugs. However, two things get called into question. First, just because the PHP team has committed a patch, doesn't mean the bug is fixed. We've witnessed a few occasions were the fix wasn't thorough enough or improperly applied. One of the MOPB bugs (#32) actually points to a new security problem introduced by the ad-hoc fix of MOPB bug #31. So while the speed of the PHP developers in committing patches is high, we can't necessarily say the same of the quality and thoroughness of the fixes. Second, even if all the fixes are committed to the development source code repository (CVS), we still have to wait for when the PHP team rolls the latest code into an official release. People generally don't deploy beta CVS snapshots of software on their production systems-so those fixes won't see widespread deployment an official release is tested and made. And right now, there's no telling when that will happen. We hope it will occur almost immediately after the MOPB ends, but ultimately we will have to wait and see.
Even when there is an official PHP release, there can still be additional delay for various OS/package distributors (i.e. Linux, BSD) to turn the PHP release into a distribution package. For example, if you're a SuSE user, and you are using the SuSE RPM version of PHP, then after the PHP team releases the next version (i.e. 5.2.2 and/or 4.4.6), you still have to wait until SuSE either makes a new PHP RPM or back-ports the fixes to whatever PHP version branch they are using.
Curiosity got the better of us, so we decided to look at the various development mailing lists of many popular OS distributions (OpenBSD, FreeBSD, SuSE, Debian, and Fedora). We searched CVS commit lists, development discussion lists, and ports commit lists for any reference to PHP made on or after March 1st. We found OpenSuSE was the only one to have committed fixes for the MOPB bugs to their distribution package repository. SuSE also made a public statement in their latest Security Summary Report indicating they are watching the progress of the MOPB campaign and plan to act after it concludes. But aside from those two cases, our cursory look into the development efforts of some popular OS distros didn't turn up any current efforts to dealing with any of the problems uncovered by the MOPB effort. We do want to explicitly note that this isn't necessarily a bad thing-it is understandable to wait until the conclusion of the MOPB campaign before acting. Plus, this doesn't reflect any private development efforts that haven't been committed into CVS yet. Regardless, it's still an interesting observation.
Overall this is an interesting time for PHP users. While there will be a little bit of turmoil in the release and deployment of the next PHP version, overall Esser and the MOPB crew have successfully bolstered the security of PHP. Combined with their ongoing efforts on the free Hardened-PHP and Suhosin security enhancements for PHP, I think one thing is clear: Esser and the MOPB crew truly are just trying to make the world a more secure place for PHP users. And for that, we should thank them.
Resources: Month of PHP Bugs: http://www.php-security.org/
Month of PHP Bugs: Mid-month analysis http://portal.spidynamics.com/blogs/jeff/archive/2007/03/19/Month-of-PHP-Bugs_3A
00_-Mid_2D00_month-analysis.aspx
Hardened-PHP project: http://www.hardened-php.net/
Suhosin PHP security extension: http://www.hardened-php.net/ suhosin/index.html
Questions: http://portal.spidynamics.com/blogs/spilabs/default.aspx
______________________________________________________________________
Subscriptions: @RISK is distributed free of charge to people responsible for managing and securing information systems and networks. You may forward this newsletter to others with such responsibility inside or outside your organization.