June 19, 2021

Eight Year Old PHP / Apache mod_cgi Vulnerability Disclosed

(LiveHacking.Com) – Due to a bug in PHP’s bug tracking system, a privately disclosed security vulnerability in the way PHP handles query string parameters when it is running in CGI mode, was marked as public. As a result the PHP project has released PHP 5.3.12 and PHP 5.4.2 to fix the problem, however there are reports that these releases are buggy and don’t fully resolve the problem.

The initial details of the generic PHP-CGI remote code execution bug were posted on the eindbazen.net website. They discovered that the query string ‘?-s’ results in the “-s” command line argument being passed to PHP, resulting in source code disclosure. Further investigation showed that the command-line switches -s, -d or -c are passed to the php-cgi binary, which can also be exploited to obtain arbitrary code execution.

To test if your site is vulnerable try the following:


According to the release information: “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.”

The official fix in PHP 5.3.12 and PHP 5.4.2 contain a bug which makes the fix trivial to bypass, it is therefore recommended that system admins mitigate this problem by adding the following Apache mod_rewrite rule:

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

The bug was originally discovered in January and was used to pwn the Nullcon Hackim 2012 scoreboard. The PHP team were contacted but after a couple of weeks little seemed to be happening. US-CERT was contacted who acknowledged the receipt of vulnerability in February. By May US-CERT notified eindbazen.net that the PHP team was testing a patch. However on May 3rd the bug reported was mistakenly marked as public and picked up on reddit /r/netsec /r/opensource and /r/technology. US-CERT have now published a Vulnerability Note.

It is anticipated that a new PHP update, with a revised fix, will be released soon.

Apache Reverse Proxy Vulnerability Exposes Internal Servers

(LiveHacking.Com) – The Apache foundation has issued a security advisory regarding the use of the Apache HTTP Server in reverse proxy mode. If the server is configured using the RewriteRule or ProxyPassMatch directives with pattern matching, it is possible to unintentionally expose servers on your internal network that should be hidden by your firewall.

The problem is that the Apache HTTP server does not check that the incoming URL is valid. This means that attackers who send specially formed requests can force the pattern matching algorithms to expand the input to an unintended target URL.

The problem was originally found by Context Information Security Ltd who then worked with Apache to produce a patch which reduces the risks of an attacker exploiting a misconfigured server.

According to the advisory:

For future releases of the Apache HTTP Server, the software will validate the request URI, correcting this specific vulnerability. For future releases, the server has been patched to reject such requests, instead returning a “400 Bad Request” error. The documentation has been updated to reflect the more general risks with pattern matching in a reverse proxy configuration.


A configuration like one of the following examples:

RewriteRule (.*)\.(jpg|gif|png) http://images.example.com$1.$2 [P]
ProxyPassMatch (.*)\.(jpg|gif|png) http://images.example.com$1.$2

could result in an exposure of internal servers. A request of the form:

GET @other.example.com/something.png HTTP/1.1

would get translated to a target of:

http://images.example.com () other example com/something.png

This will cause the proxy to connect to the hostname “other.example.com”, as the “images.example.com@” segment would be treated as user credentials when parsing the URL. This would allow a remote attacker the ability to proxy to hosts other than those expected, which could be a security exposure in some circumstances.

The request-URI string in this example, “@other.example.com/something.png”, is not valid according to the HTTP specification, since it neither an absolute URI
(“http://example.com/path”;) nor an absolute path (“/path”).


The Apache foundation have released a patch and also recommend system administrators check the use of the RewriteRule and change them according to the example below:

RewriteRule (.*)\.(jpg|gif|png) http://images.example.com$1.$2 [P]
RewriteRule /(.*)\.(jpg|gif|png) http://images.example.com/$1.$2 [P]

to ensure the pattern only matches against paths starting with a “/”.

New Apache Version with Further Fixes for Handling Byte-range Requests

(LiveHacking.Com) – The Apache Foundation has released version 2.2.21 of the Apache HTTP Server. This version of Apache is mainly a security and bug fix release:

  • SECURITY: CVE-2011-3192 (cve.mitre.org) core: Further fixes to the handling of byte-range requests to use less memory, to avoid denial of service. This patch includes fixes to the patch introduced in release 2.2.20 for protocol compliance, as well as the MaxRanges directive.
  • SECURITY: CVE-2011-3348 (cve.mitre.org) mod_proxy_ajp when combined with mod_proxy_balancer: Prevents unrecognized HTTP methods from marking ajp: balancer members in an error state, avoiding denial of service.

A couple of weeks ago the discovery of a vulnerability in Apache left millions of web sites vulnerable to DoS attacks.  The problem revolves around how Apache handles byte range headers and was fixed in version 2.2.20. Apache 2.2.20 does fix this issue; however with a number of side effects. Version 2.2.21 corrects a protocol defect in 2.2.20, and also introduces the MaxRanges directive.

Apache HTTP Server 2.2.20 Released – Fixes Byte-range DoS Vulnerability

(LiveHacking.Com) – The Apache Foundation has released an update to its HTTPD server to fix the much publicized byte range headers problem.  The announcement notes just one fix:

  •  CVE-2011-3192: Fix handling of byte-range requests to use less memory, to avoid denial of service. If the sum of all ranges in a request is larger than the original file, ignore the ranges and send the complete file.

The vulnerability left over 60% of the world’s websites exposed to a denial of service attack. The problem revolved around how Apache handled byte range headers and due to a tool, which was published to demonstrate the problem, an attack could be easily  launched  and cause very significant memory and CPU usage on the target server.

Range Header DoS Vulnerability Leaves 60% of All Websites Open to Attack

(LiveHacking.Com) – Over 60% of the world’s websites are run using the Apache web server and a recently found vulnerability in Apache has left these millions of web sites open to a denial of service attack.

According to the official Apache HTTPD security advisory, the problem revolves around how Apache handles byte range headers. The advisory links to a tool which is available called “killapache.pl” which effectively demonstrates the problem. Active use of this tool has been observed. The attack can be done remotely and with a modest number of requests can cause very significant memory and CPU usage on a server.


Apache HTTPD users who are concerned about a DoS attack against their server should consider implementing any of the following mitigations immediately.

1) Use SetEnvIf or mod_rewrite to detect a large number of ranges and then either ignore the Range: header or reject the request.

Option 1: (Apache 2.0 and 2.2)
# Drop the Range header when more than 5 ranges.
# CVE-2011-3192
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range

# optional logging.
CustomLog logs/range-CVE-2011-3192.log common env=bad-range

Option 2: (Also for Apache 1.3)
# Reject request when more than 5 ranges in the Range: header.
# CVE-2011-3192
RewriteEngine on
RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
RewriteRule .* - [F]

The number 5 is arbitrary. Several 10’s should not be an issue and may be required for sites which for example serve PDFs to very high end eReaders or use things such complex http based video streaming.

2) Use mod_headers to completely dis-allow the use of Range headers:

RequestHeader unset Range

Note that this may break certain clients – such as those used for e-Readers and progressive/http-streaming video.

A patch or new apache release for Apache 2.0 and 2.2 is expected
in the next 48 hours. Although still popular, Apache 1.3 is deprecated and as such there will be no official patch.

Apache 2.2.19 Released: Security Update and Bug-fix

The Apache HTTP Server Project team released the new version 2.2.19 of the Apache HTTP Server (httpd).

This new version is a security update and bug-fix release to address CVE-2011-1928 and CVE-2011-0419 DoS vulnerabilities. This release also corrects a versioning incompatibility in 2.2.18 and it is a major release of the stable branch, and represents the best available version of Apache HTTP Server according to the project’s website.

The Apache 2.2.19 includes some new features such as Smart Filtering, Improved Caching, AJP Proxy, Proxy Load Balancing, Graceful Shutdown support, Large File Support, the Event MPM, and refactored Authentication/Authorization.

This new release includes the Apache Portable Runtime (APR) version 1.4.5 and APR Utility Library (APR-util) version 1.3.12, bundled with the tar and zip distributions. The APR libraries libapr and libaprutil (and on Win32, libapriconv version 1.2.1) must all be updated to ensure binary compatibility and address many known security and platform bugs.

Apache HTTP Server 2.2.19 is available for download here.