• Update to PHP 5.2.1 and watch out for the next version and update to it as soon as it comes out. Do not PHP4, because there is a vulnerability which will not be fixed by the developers (because PHP4 is considered old code).
• Install Suhosin (unfortunately it is currently only available for Linux)
• If you have the Zend platform installed, take on look here to see if you are vulnerable to these exploits
• Disable the following functions (there are some very common functions here, so unless you run your own server, you won’t be able to generally disable them):
  • phpinfo()
  • substr_compare() – if you really need this function, you can find a replacement for it written in PHP on the documentation page (I didn’t test it, but it looks like it should work).
  • mb_parse_str()
  • iptcembed() – already disabled if you disabled the GD extension
• Disable the following extensions (they are rarely used, so in case you are a shared hosting, most probably you can get away with disabling them – of course if you host your own servers you should disable all the extensions which you don’t use!):
  • WDDX
  • Ovrimos (in PECL, but you may have installed it with an older version of PHP)
  • The zip extension from PECL
  • bz2_filter
  • SQLite – the issues with it are fixed in PHP 5.2.1, however be sure to read the description here before relaxing (because you might use a different version than you think).
  • the GD extension – this is relatively widely used, so you can get away with disabling it only if you own you own server

Also my previous recomendations remain valid:

• Run PHP as CGI rather than shared module
• Configure your firewall rules strictly (if you don’t have anything on port 4444, do not open port 4444!)
• Consider using mod_security. While it is not perfect, it provides you with an added layer of security
• If you are using a shared host account, consider moving to dedicated servers of VPS’s! If you decided against it, consider it again! Think about this

Of course even you apply all these measures you won’t be 100% safe, because some bugs remain unfixed and Esser hinted that he might be back later this month with an other month worth of PHP bugs.

• 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).

Update: I don’t know if this is the same, but SANS pointed me to this Microsoft advisory: MS06-075 – Vulnerability in Windows Could Allow Elevation of Privilege.

Update to the update: maybe it isn’t the same because SANS points out that this was patched in the last round of updates and the eEye advisory refers to something unpatched.

This is exactly the case with this individual. He refers to a very old attack vector when creating a DLL with the same name as one that was loaded by the application resulted in loading the “malicious” DLL. As of WinXP SP2 (which everyone should have installed by now, otherwise your computer won’t last for 10 minutes on the Internet), the search order for DLLs is the following (taken from the official MS page):

1. The directory from which the application loaded.
2. The system directory.
3. The 16-bit system directory.
4. The Windows directory.
5. The current directory.
6. The directories that are listed in the PATH environment variable.

Now lets analyze this list from the point of view of IE. The current security settings on my IE folder (in program files) is the following: Administratos – Full Control, Power Users – Modify and Users – Read and Execute. In other words you can only create files there if you have at least power user privileges, but if malicious code runs at that level you are pretty much screwed anyway as you can do much more damage than that.

Now if you run as a normal user (which you should be!), your only hope is to write to a directory in the path (or alternatively change your path so that it includes a given directory). In this case the DLL would be loaded IF it couldn’t be found in any of the other places. This scenario is only possible if some application uninstalled itself and failed to remove the registry entry for the DLL.

To sum up:

• This vulnerability has been fixed a couple of years ago (in WinXP SP2)
• If you run your browser with high privileges, you don’t need this method to alter the system. It can be used to hide files, but then again if you have that high privileges you can directly install rootkits.
• If you run with low privileges (as you should), the only attack would only be possible if you uninstalled a program which registered a BHO without referring with the full pathname to it and the uninstaller program deleted the dll, but failed to delete the registry entry. With other words: very, very unlikely.

My advice would be: run with low privileges (as user) and don’t read articles from people who don’t know what they’re talking about.