Yet Another PHP Security Blog

Two versions of PHP were just released and fix different security issues. With that, I think the problems that caused a stir last week are now fixed. Read more here: PHP 5.4.3 and 5.3.13 fix several security issues.

Further reading on php.net:

• Release announcement: PHP 5.4.3/5.3.13 release announcement
  
• Download page: PHP 5.4.3, 5.3.13
  

So PHP 5.4.2 and 5.3.12 do not fix the security issue reported in CVE-2012-1823 and discussed here earlier. The original advisory has a number of mitigation opportunities and an additional patch, and PHP.net has a RewriteRule online as a hotfix.

Update As mentioned on Eindbazen: The current fixes have a problem with whitespace BEFORE the actual Query String, i.e. “/?+-s”. This only applies in the wrapper environment outlined by eindbazen.net where command-line arguments are passed without double quotes to PHP, as in /usr/bin/php5 $@.

I want to discuss now shortly if any of these properly mitigate the issue.

1. PHP 5.4.2 does not mitigate the issue.
   
2. RewriteRule on php.net: The RewriteRule posted on PHP.net is useless. I can’t go into much detail here but it does not mitigate the issue properly.
   
3. RewriteRule on bugs.php.net: The comments in the original advisory show a RewriteRule that was posted on bugs.php.net originally. I tried this against an unpatched PHP 5.3.3-7+Squeeze8 and it seems to correctly filter all malicious query strings, including my variations. It has a tiny bit of overshoot though (for example, passing negative integers to the query string will trigger a 403), but it’s not practically relevant, I think.
   
4. Binary Wrapper and Option-stripping patch on eindbazen.net: The guys who wrote the original advisory wrote a patch and a php-cgi wrapper that strips all “-xyz” options respectively skips option processing when in CGI mode. This works well, too.
   
5. Patch “third option” on eindbazen.net: This patch does not properly mitigate the issue.
   

So, right now you will probably want to use the following RewriteRule:

RewriteEngine on

RewriteCond %{QUERY_STRING} ^[^=]*$

RewriteCond %{QUERY_STRING} %2d|\- [NC]

RewriteRule .? - [F,L]

This is the easiest way to hot-fix the issue until a working PHP version is released.

In the meantime, CVE-2012-2311 has been issued to address the fact that PHP 5.4.2 and 5.3.12 (which I never tested, btw, but the patch is identical) do not properly fix the problem.

Read the original advisory here and my earlier article here.

This article contains various edits to account for recent developments. Stay tuned.

Some folks found an interesting bug while playing CTF at Nullcon 2012. If you run PHP as a plain CGI or via mod_cgid (not FastCGI), you can pass command-line arguments like the “-s” switch (“show source”) to PHP via the query string.

For example, for any PHP-CGI script on your machine, you could see the source via “http://localhost/test.php?-s”. In this case, your web server’s access restrictions still apply. There is more parameters in the PHP-CGI binary (try “php-cgi -h” for a list) which can be used. Some are not available directly (for example, the infamous “-r” parameter that allows to directly pass code for execution doesn’t work), but others are ready for (ab-)use.

This constitutes an easy way to do the following:

• Find out database passwords, file locations etc.
  
• DoS the server
  
• Execute any file on the server’s local disk
  
• If you have the possibility to upload a file to the server, execute any code
  

I haven’t found a way to reliably execute remote code without a file upload possibility, but I am sure there are better exploit writers than me already working on this. As far as I understand the original advisory, there is a trivial RCE possibility that I have probably missed.

Remote Code execution is universally possible and not mitigated by any current security setting or extension. There are workarounds (see below).

As the authors of the advisory point out, several months have passed since initial reporting. The PHP team does not currently seem to have a universally compatible fix, so there are several external ways for mitigation (also mentioned in the advisory). However, emergency releases are scheduled for tomorrow, May 4th, according to well-informed sources. It’s not quite clear why the fix took so long (and if the disclosure timeline in the advisory accurately reflects both sides of the incident), but the fact that someone accidentially disclosed the bug on reddit sure didn’t help.
Read the original advisory here: http://eindbazen.net/2012/05/php-cgi-advisory-cve-2012-1823/

Update: PHP 5.3.12 and PHP 5.4.2 have just been released and at least 5.4.2 does not, I repeat does not fix the bug. Right now, mod_rewrite or other external mitigation seems the only way to circumvent the issue. PHP 5.3.12 / 5.4.2 release statement

More Updates and PoC exploit in the extended section

Continue reading "New PHP-CGI exploit: CVE-2012-1823, PoC exploit"

With the recently released PHP 5.4, the Suhosin patch and extension were removed from many Linux distribution packages (i.e., Debian et al.) and until three weeks ago, there was no possibility to compile and run the Suhosin extension under PHP 5.4. This little howto shall serve as installation instruction for Debian Wheezy users - your mileage may vary. I blogged about this here

First, make sure you have the appropriate PHP modules installed for your distribution. In Wheezy, you will need at least php5-common, php5-dev and one or more or these: libapache-mod-php5filter, php5-cli, php5-cgi

You can install them with

apt-get install php5-common php5-dev php5-cli

for example.

Next, we will download, compile and install the Suhosin extension. There is a .tar.gz download here: Github/stefanesser. Download this file to your /usr/local/src directory:

cd /usr/local/src

wget https://github.com/stefanesser/suhosin/tarball/master

tar zxvf master

Now, let’s compile the thing.

cd /usr/local/src/stefanesser-suhosin-716a292

phpize
This should yield the following output:

Configuring for:

PHP Api Version:         20100412

Zend Module Api No:      20100525

Zend Extension Api No:   220100525

After this, you can run the usual configure command:

./configure

checking for grep that handles long lines and -e... /bin/grep

[..]

config.status: executing libtool commands

Then compile:

make

[..]

Build complete.

Don’t forget to run ‘make test’.

The last step is installation.

 make install

Installing shared extensions:     /usr/lib/php5/20100525/

Now the extension is installed, but not yet configured or activated. Fortunately, Stefan has provided a default configuration file in the distribution tarball that you can just copy over.

cp suhosin.ini /etc/php5/conf.d

If you execute php -v, you should now see the following:

PHP 5.4.0-3 (cli) (built: Mar 21 2012 20:33:26) 

Copyright (c) 1997-2012 The PHP Group

Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies

    with Suhosin v0.9.34-dev, Copyright (c) 2007-2012, by SektionEins GmbH

After restarting your web server with /etc/init.d/apache2 restart, you should have a working Suhosin with PHP 5.4!

There’s a very good writeup by fellow security analyst Moxie Marlinspike in the ThreatPost blog that details the current issues with SSL and trust roots - and although a little short on actual mitigation ideas - pretty much nails all the problems that we currently have. As a little sugarcoating, he also dismantles the notion that DNSSEC is “our savior”.

And there’s a clever little jab at GoDaddy.

Go find the article here at ThreatPost.