On PHP.net there's a quick security advisory for those that didn't see the news - the wiki.php.net machine was compromised but has been wiped and all accounts reset and requiring a password reset.

The wiki.php.net box was compromised and the attackers were able to collect wiki account credentials. No other machines in the php.net infrastructure appear to have been affected. Our biggest concern is, of course, the integrity of our source code. We did an extensive code audit and looked at every commit since 5.3.5 to make sure that no stolen accounts were used to inject anything malicious. Nothing was found. The compromised machine has been wiped and we are forcing a password change for all svn accounts.

The issue was caused by a combination of a problem with the wiki software and a Linux root exploit. The Register has additional comments about the issue and outage.

As reported by both The Register and Zend, there's a new remote exploit bug that possibly has something to do with the way 32-bit processors handle floating point numbers.

From Zend:

Due to the way the PHP runtime handles internal conversion of floating point numbers, it is possible for a remote attacker to bring down a web application simply by adding a specific parameter to a query string in their web browser.

The bug, found here on bugs.php.net, has been reproduced on Windows and 32-bit linux systems and can cause the server hang and/or crash as a result. The real issue comes from this bug on the x87 FPU design. The bug has already been fixed in the latest SVN versions (including 5.2 that was end-of-life recently). A release to fix the issue should be coming shortly.

Some of you might have heard about the hacking of the phpBB.com website earlier this week. Well, Stefan Esser has posted a bit more about the vulnerability in the PHPList software that lead to the problem.

A few days ago phpbb.com was hacked through a super-globals-overwrite vulnerability in PHPList that was used by an attacker for a local file inclusion exploit. Details about the whole attack, written down by someone who claims to be the attacker, can be read here.

Stefan talks about the superglobal problem PHPList had - allowing the superglobal information to overwrite the variables inside the script without so much as a check. Example code shows how it was possible for the attacker to provide their own configuration file value to be opened via a stream wrapper.

From the GNUCitizen blog, there's a new post about a recent meeting (of the OWASP London Chapter) where several presentations were given on methods for exploiting PHP applications. The three talks given were:

• Rodrigo Marcos - hacking PHP sockets for fun and profit
• David Kierznowski - exploitation techniques using real world examples
• Colin Watson - talk about security badges

There's links to the slides for one the formal presentations, the exploitation techniques - two sets: the remote exploit examples and local exploit examples.

Gareth Heyes has a new post today talking about one of the vulnerable values in the $_SERVER superglobal - PHP_SELF.

I thought it might be a good idea to gather a few test cases demonstrating the problem. Why PHP allows these URL's is beyond me and it wouldn't take much work to filter out these malicious URL's in the PHP code.

He provides four test cases to show how simple it is to abuse - one using a HTTP header, another pushing XSS through, the third mentions search pages and the fourth a direct code injection.

You can download the code here.

Gareth Heyes has an example of yet another way he's seen developers incorrectly handle incoming connections and the information inside. This time, he focuses on the remote IP coming from the client.

Developers place too much trust in everything, they assume that certain data cannot be faked and therefore these pieces of data can be used as a Trojan horse. Lets take the REMOTE IP of a user, it seems a trusted source because of the TCP/IP connection between the user and the server.

He points out the difference between HTTP_X_FORWARDED_FOR and REMOTE_ADDR and how, despite them being the same almost all of the time, shouldn't be trusted since they could be spoofed. He even includes an example script showing how it could be done (and how a bit of Javascript can even be inserted).

The Ubuntu linux group has released an update for their PHP packages to help protect their users from issues like security bypass and remote exploits.

This fixes a weakness and some vulnerabilities, where some have unknown impacts and others can be exploited by malicious, local users to bypass certain security restrictions and by malicious users to bypass certain security restrictions.

Packages can either be downloaded manually or via the linux distro's package manager. This advisory also applies to the corresponding versions of Kubuntu, Edubuntu, and Xubuntu.

As mentioned in this new advisory on the Secunia website, the Slackware linux group has posted their latest updates to their PHP package (in light of the released of PHP 5.2.4).

Slackware has issued an update for php. This fixes a weakness and some vulnerabilities, where some have unknown impacts and others can be exploited by malicious users and malicious, local users to bypass certain security restrictions.

The update is marked as "moderately critical" so it's recommended that you update as soon as possible. The packages can be downloaded from the Slackware website (from the FTP sites they link to in the original advisory).

Builder.com.au has a new article today about the recent image issue - the PHP code embedded inside the GIF - that's come up on several sites.

The exploit code slipped through the site's defenses with the aid of a legitimate image at the beginning of the file, according to a blog post on the Sans Institutes's Internet Storm Center. [...] Malicious attackers planted PHP coded exploit script within an image file. PHP is often used as a programming language to create dynamic Web sites.

The article reports that, while this exploit hasn't happened much, the occurrences of it's use are growing with victims in a wide range of classifications - from small personal sites out to a certain major image hosting site. This same issue was discussed here on the PHPClasses.org website as well.

On the PHPClasses site today, there's a new post that points out an issue that could happen with dyanamic GIF creation in a PHP script leading to a security exploit.

Manuel Lemos writes:

The problem that was discovered is that you can insert PHP code in the middle of a GIF image. That would not be a problem if it was not for the insecure ways some developers use to serve images upload by their users. Usually, uploaded files are moved to a given directory. If the site then serves the images directly from that directory and preserve the original file name, the site may be open for security exploits.

The problem comes when a user decides to upload an "image" file that's actually a PHP script (ending in PHP even) to the remote system. When this is outputted, it's placed inside the image tag and executed with each page load. Manuel offers a suggestion to prevent the issue - protecting the images directory and using readfile to grab the contents of the file to output rather than just a straight echo.