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.

As Christopher Kunz points out, Serendipity users should check out a new blog posting over on the CMS system's website concerning an immediate update they've released.

Serendipity 1.1.3 and 1.2-beta2 have been released due to a SQL injection attack reported by Dr. Neal Krawetz today. It is possible to abuse a 'commentMode' variable to inject SQL code that was targeted to the function that fetches comment information. This variable was introduced to Serendipity 1.1 - all prior versions are not affected.

They also suggest checking you access logs for a "commentMode" variable issued in requests to see if there were any kind of attacks made already. The fix is a simple matter of editing the functions_comments.inc.php file and replacing the line of code they give with the more secure versions. Again, this is recommended as an immediate upgrade for Serendipity users.

In this new post to the PHP Security blog today, Stefan Esser gives a good recommendation to developers out there looking to provide the most recent protection for their applications - look to the CVS.

One of the worst things in PHP security is the fact that vulnerabilities in PHP are usually patched in the CVS and then wait for months until they are disclosed to the public. Time enough for everyone to grab the fixes from CVS and develop exploits for the vulnerabilities. Therefore PHP vulnerabilities are usually already known to the bad guys for weeks or months when a new PHP version comes out and the public is notified about the vulnerability.

He also notes that there are sometimes when it happens that issues aren't represented in the materials that go out with each release. One he mentions specifically involves this bug.

Just in case you haven't heard yet and are running WordPress version 2.1.1 (that you've downloaded recently), you need to upgrade your installation because of a security exploit that made its way into the software.

From the WordPress Blog:

Long story short: If you downloaded WordPress 2.1.1 within the past 3-4 days, your files may include a security exploit that was added by a cracker, and you should upgrade all of your files to 2.1.2 immediately.

If you have even a doubt as to if you're running the bad version, go ahead and upgrade to version 2.1.2. Somehow, an individual gained access to the servers where the package is hosted and altered some of the code in the download file. This resulted in a method to bypass any security in place and allow the attacker full control.