As the days pass by, new vulnerabilities are disclosed on the Month of PHP bugs. An important (and very useful) change is that markings have been added to the main page which show the vulnerabilities that are not addressed in the latest (5.2.1) release and the ones which are not directly related to PHP (for example there is a bug which lets you bypass mod_security). The new (since my last post) vulnerabilities break down as follows:

• 1 mod_security bypass – present in the latest release version (2.1.0)
• 1 bug in the PHP4 Ovrimos extension – disable the extension since it seems to be particularly bug ridden (also, remember to enable the minimum set of extensions which is necessary for your code to function)
• 1 arbitrary code execution in the PECL ZIP – disable this extension now! Given that this is not part of PHP Core, we might see an update sooner. On the flip side, arbitrary code execution is bad, because if you (as most of the people) load PHP as an Apache module (for performance reasons), the current PHP interpreter equals the current Apache process, which can contain sensitive information (like SSL certificates!)
• 2 memory read exploits – the first one (not patched in 5.2.1) allows a limited range memory read, but still enough to read some special values (like stack canaries). The second one (which is luckily addressed by the latest release – one more reason to upgrade!) allows arbitrary memory read in the current process (which is Apache if PHP is loaded as a dynamic library).
• The PHP filtering extension also had it share of problems with 2 bugs, which could result in not 100% sanitization of the input, luckily both are fixed in the latest release.

My opinion / advice: in the light of these vulnerabilities (and other, much older issues), shared servers with PHP are almost inherently impossible to secure. Go with a separate server or at lease a Private Virtual Server if possible at all. Apply layered security. One of the advisories said:

This bug shows one of the weaknesses behind the ext/filter idea. Whenever there is a bug in the filter implementation all applications that make use of it are vulnerable and can only be fixed by upgrading the PHP version (because the filter extension is static by default).

This is true, however you shouldn’t draw the conclusion that these solutions are useless (or that mod_security is useless, just because a bug was found). Such reasoning misses the point. Lets say that normally your system is vulnerable to X exploits. After you install some security add-on (like mod_security of Suhosin), your system is vulnerable to Y exploits. As longs as Y is less than X (and most of the time it is considerably less), it is worth considering the deployment of that product (and I emphasize considering, because you must think about many other issues before deploying such products, like how many applications / scripts will it break and how much time does it require for fine-tuning). And just because Y is not 0, doesn’t mean that you should avoid using the product and stay vulnerable to a much larger set of problems.

Finally, you should consider going the FastCGI route to separate the script interpreter from the web server (in fact you should go the plain CGI route, but this may yield performance which is unacceptable).