Can query string command line exploits in older CGI implementations of PHP be protected against without updating PHP versions?

Question

We recently received this from a security audit:

PHP is a general purpose scripting language that can be embedded into HTML. A vulnerability exists in PHP versions prior to 5.3.12 and 5.4.2 due to improper parsing of query string parameters when configured with a CGI-based setup (e.g., Apache's mod_cgid). Processed query string parameters supplied to an arbitrary PHP file are improperly parsed as command line arguments. Remote attackers could leverage this issue to pass command-line switches (e.g., -s, -c, -n, -f, -r, -B, -R, -F, -E, -t, etc.) to the php-cgi binary and disclose potentially sensitive source code information or execute arbitrary code on vulnerable systems with the privileges of the web server. Successful exploitation requires that the HTTP server complies with section 4.4 (The Script Command Line) of The Common Gateway Interface (CGI) Request for Comments (RFC 3875).

We have multiple PHP environments, all running as CGI/Fast CGI under IIS. Updating all the PHP versions is of course the ideal long-term solution. However, that will take some time, testing, and planning. Some of the servers are managed by external hosts we contract with, which will further complicate version upgrades.

How can I check specific environments for this vulnerability? Is there a way to prevent remote attackers from exploiting this without a full version upgrade?

Answer 1

PHP released a bulletin here:

The PHP development team would like to announce the immediate availability of PHP 5.4.2. This release delivers a security fix.

There is a vulnerability in certain CGI-based setups that has gone unnoticed for at least 8 years. Section 7 of the CGI spec states:

Some systems support a method for supplying a array of strings to the CGI script. This is only used in the case of an `indexed' query. This is identified by a "GET" or "HEAD" HTTP request with a URL search string not containing any unencoded "=" characters. So requests that do not have a "=" in the query string are treated differently from those who do in some CGI implementations. For PHP this means that a request containing ?-s may dump the PHP source code for the page, but a request that has ?-s&a=1 is fine.

A large number of sites run PHP as either an Apache module through mod_php or using php-fpm under nginx. Neither of these setups are vulnerable to this. Straight shebang-style CGI also does not appear to be vulnerable.

If you are using Apache mod_cgi to run PHP you may be vulnerable. To see if you are just add ?-s to the end of any of your URLs. If you see your source code, you are vulnerable. If your site renders normally, you are not. To fix this update to PHP 5.3.12 or PHP 5.4.2. We recognize that since this is a rather outdated way to run PHP it may not be feasible to upgrade these sites to a modern version of PHP, so an alternative is to configure your web server to not let these types of requests with query strings starting with a "-" and not containing a "=" through. Adding a rule like this should not break any sites. For Apache using mod_rewrite it would look like this:

RewriteCond %{QUERY_STRING} ^(%2d|-)[^=]+$ [NC]
RewriteRule ^(.*) $1? [L]

If you are writing your own rule, be sure to take the urlencoded ?%2ds version into account.

Note that this is specifically for mod_cgi on Apache.

To make sure that you aren't vulnerable, test if the method described above is also applicable for your IIS servers. If so then you need to make sure that for each IIS server you need to enable url-rewrite and make sure you mimic the same behavior as written above.

The longterm solution isn't patching your software, your long term goal should be adequate patch management and a better control of your software development lifecycle. Patches like these should be able to be rolled out in less than two weeks (this is the goal).

You should also take care that you keep track of vulnerabilities yourself, the fact that the audit team has to remind you about critical vulnerabilities shows that your vulnerability management is lacking as well.