The month is nearing to an end (but fear not, next month we will have a month of MySpace bugs it seems), and here are the latest developments:

• Two bugs using which you can bypass the open_basedir restriction. They are in the user-contributed PECL modules, so there is a chance that they will be fixed before a PHP update. The bad news is that this agains shows that running on a shared server provides minimal security and you really should go with your own server.
• Some local code execution vulnerabilities! What this means is that anyone capable running PHP code on the same system (virtual or otherwise) can escape the PHP sandbox and directly run binary code! This means that any built-in PHP protection (like disable_functions or open_basedir) become useless! Also, remember that if your scripts (or other users scripts running under the same account – in case of a shared hosting) contain a remote include vulnerability, the attacker doesn’t even have to have an account to run arbitrary PHP code!
• A vulnerability to activate register_globals, even if it has been deactivated from the php.ini (or .htaccess). As it stated in the advisory:
  

  The danger of this vulnerability is that nowadays many scripts try to protect themself against register_globals being activated by warning the user that it is activated, by refusing to work while it is activated or by trying to undo it, when it is activated.

  However when this vulnerability is exploited the script is unable to realise that register_globals is activated (without dirty tricks) and therefore believes it runs with register_globals deactivated.

  The solution (when you code PHP) is to properly initialize variables before using them (and not relying on them havin the 0 / empty string / null value).

• An error in the unserialize code. This can be triggered remotely if the script uses serialized data to pass state information between script invocations. Fortunately this is only an information disclosure vulnerability.

The conclusion seems to be that PHP is completely inadequate to run any external-facing web-services (which is a real shame given all the useful applications developed in it). As a mitigating measure one should move away from shared servers and implement multiple layers of security, like:

• An application firewall like mod_security
• A firewall on each host, with proper rules like (a) not allowing the host running the webserver to be contacted on any other port than 80 or 443 (many shellcodes open ports and listen there for connections) (b) not allowing the host to make outbout connections (this protects against reverse shells and bots which use IRC for command and control) and (c) only allowing connexions to back-end hosts (like a database server) from known sources (like your webserver).
• Use different (and long) passwords for different accounts so that one compromised password doesn’t result in further compromise.