Richard Thomas comments on a "funny little PHP 'virus'" that he's noticed coming to him via emails:

Got an email that claimed to be from my host, it used a generic return address and talked about security upgrades and such and how due to new policy to help keep a secure data center I was required to upload and run 1 of 2 files in a zip attachment, the first was a php file the other was an asp file.

Of course, it wasn't from the host, so he investigated a little further to find out exactly what was going on with the file. Basically, it was a modified nsTView file with some added emailing and password discovery code. The code was "hidden" though - through a base64_encode call on one side and then decoded it on the other to cause the server to execute the code. He even posts and example of what the base64ed code might look like.

On the PHP Security Blog, Stefan Esser has posted some of his own opinions on the latest PHP release - version 5.2 - and some of the security implications of it.

Often users have requested that PHP allows disabling URL support for include and require statements while allowing it for the other filesystem functions. Because of this it was planned to have allow_url_include in PHP 6. After some discussion the feature was backported to the PHP 5.2.0 tree.

He also notes that, unfortunately, this functionality only protects against the http(s) and ftp(s) kinds of URLs and not some of the new data URLs included in the functionality of PHP 5.2. He gives two code examples of this kind of issue - one using the "pph://input" and the other using a base64 encoded value.