As I write this, I'm reviewing some of the latest and greatest patches for the applications that I've learned to love. Drupal, SugarCRM, dotProject, Mediawiki, and some secret sauce form the foundation and almost the entire infrastructure of CaseySoftware. More importantly, they form the foundation of almost every project since we began just over two years ago. Therefore, I couldn't let Stefan Esser's "Month of PHP Bugs" pass unmentioned.

Starting tomorrow, you might say the script is about to hit the fan. ;)

Stefan - a founder of the Suhosin, a PHP hardening patch/protection layer - recently left the PHP Security Response team out of frustration on how bugs, fixes, and attributions are handled. While I can't validate his claims, I have to admit that this could be a great or horribly risky way to go about getting a point across.

Let's face it, this could be a huge threat... bigger and badder than most of us have ever had to deal with. The standard tactic of "filter input, escape output" isn't going to help much of at all. Those practices happen at the application level. Some data filtering and validation (white or blacklisting) might protect you from things like buffer overflows, but without a clear understanding of the types and severity of these issues, we can't definitively say that these practices will protect us here either.

Alright, Keith, so we're all in trouble. Should we just give up and live in trees?

Well, not quite. First, you can close the secuirty issues and problems that you already know about. Most applications have an issue or two that you or the developers know about. Odds are that they should have been closed long ago, but no one is perfect.

Second, you can work to close the issues in different ways. A few releases ago, we closed a couple issues within dotProject concerning a pair of register_globals explots. Yes, most developers should have register_globals off anyway, but I released and committed a .htaccess fix to close off the same thing. Finally, in the most recent release we closed the potential issue in a third and final way. Any one of them should have closed the issue, but by closing it each way independently, we have the benefit of closing off the opportunity for other potential issues that we can't see at this point.

Finally, you can update your PHP installations. The core PHP group should release updates, patches, and configuration options to resolve these things. Hopefully, they'll be able to respond as quickly as the items are released. This one can be problematic. I was bitten by this one last week when Dreamhost updated and I wasn't prepared for it. If you have control over your server and the flexibility to schedule a bit of downtime, you shouldn't have any problems. If you're in a shared hosting environment with a less-than-responsive hosting company, well... good luck.