I previously blogged about the Month of PHP Bugs [MOPB], an effort lead by Stefan Esser and the Hardened PHP Project to raise awareness about vulnerabilities in the PHP language. The month has come and passed and of course I have to wonder about a few things.
1. The project ended up releasing 45 vulnerabilities over 31 days, many of them remotely exploitable. For anyone that was under the delusion that PHP was “pretty secure”, think again. Not only were some remote, many were methods for bypassing the native protection methods PHP offers like open_basedir or issues with various functions designed to filter bad input.
2. These “Month of X Bugs” always get a press blitz before it happens, but we rarely see the same news outlets cover the same thing a month later. It’s nice to see the results of the project, the number and type of vulnerabilities as well as any insights (see comments on previous blog post) the developers had.
3. The PHP project thankfully responded to many of these vulnerabilities already. PHP 5.2.1 and 4.4.5 fix a lot of security issues. Oh wait, that was released two weeks before the MOPB. Where is the next big release that fixes the unpatched issues?
All in all, a very impressive effort. Esser and the Hardened PHP Project have certainly raised the bar for the “Month of X Bugs” projects.
Hell hath no fury like a PHP developer scorned…
During the last months there have been the Month of the Browser bugs and the Month of the Kernel bugs projects that tried to raise awareness for security vulnerabilities in browsers and kernels.
After thinking a bit about this I started to wonder if I should not start a Month of PHP bugs somewhen in the first half of 2007. At the PHP conference it was once again claimed that it is not PHP that is insecure but the applications written by novice programmers. While it is true that many PHP applications are written by people with no clue about security it is absolutely not true that PHP is a secure programming language.
I think it is necessary to make ALL people aware of this. The plan is therefore to choose one of the 31 day months after January and release everyday a vulnerability in PHP itself. I would like to hear comments from the PHP community about this plan. (Be warned that anonymous rants will be deleted)
To check out the bugs, visit www.php-security.org/. I will also be adding comments to this entry pointing out some of the interesting commentary and underlying message behind this effort.
Last night I finally retired from the PHP Security Response Team, that was initially my idea a few years ago.
The reasons for this are many, but the most important one is that I have realised that any attempt to improve the security of PHP from the inside is futile. The PHP Group will jump into your boat as soon you try to blame PHP’s security problems on the user but the moment you criticize the security of PHP itself you become persona non grata. I stopped counting the
times I was called immoral traitor for disclosing security holes in PHP or for developing Suhosin (http://www.suhosin.org/).
For the ordinary PHP user this means that I will no longer hide the slow response time to security holes in my advisories. It will also mean that some of my advisories will come without patches available, because the PHP Security Response Team refused to fix them for months. It will also mean that there will be a lot more advisories about security holes in PHP.
Stefan has a history of providing well written and very technical attacks against the PHP language. If he was one of the few (only?) people that cared about security, this doesn’t bode well for PHP.