Blogging Techstacks

Apache HTTP Server 2.2.22 Released

The Apache HTTP Server project released version 2.2.22 and it's an important release, addressing 6 "significant" security vulnerabilities:

1. CVE-2011-3368 (cve.mitre.org)  -  Reject requests where the request-URI does not match the HTTP specification, preventing unexpected expansion of target URLs in some reverse proxy configurations.
2. CVE-2011-3607 (cve.mitre.org)  -  Fix integer overflow in ap_pregsub() which, when the mod_setenvif module is enabled, could allow local users to gain privileges via a .htaccess file.
3. CVE-2011-4317 (cve.mitre.org)  -  Resolve additional cases of URL rewriting with ProxyPassMatch or RewriteRule, where particular request-URIs could result in undesired backend network exposure in some configurations.
4. CVE-2012-0021 (cve.mitre.org)  -  mod_log_config: Fix segfault (crash) when the '%{cookiename}C' log format string is in use and a client sends a nameless, valueless cookie, causing a denial of service. The issue existed since version 2.2.17.
5. CVE-2012-0031 (cve.mitre.org)  -  Fix scoreboard issue which could allow an unprivileged child process could cause the parent to crash at shutdown rather than terminate cleanly.
6. CVE-2012-0053 (cve.mitre.org)  -  Fixed an issue in error responses that could expose "httpOnly" cookies when no custom ErrorDocument is specified for status code 400.

There are also some bugs fixed in this release as well—see the changelog for the full list and, like always, you can download a copy from a mirror near you.

Apache HTTP Server 2.2.21 Released

The Apache httpd server team released version 2.2.21!  This release fixes a couple security vulnerabilities as well as some other bugs.  The vulnerabilities addressed in this release are:

• 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.

• 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.

So, yeah, this release further addresses the recently patched Apache Range Header Denial of Service Vulnerability and also introduces a new configuration directive: MaxRanges.

The changelog details everything new and fixed in this release and you can download a copy from a mirror near you.

Mitigating the Apache Range Header DoS on Ubuntu Apache 2.2

If you are running apache 2.2 (the current version in Ubuntu Server on my recently created VM being 2.2.17) and you wish to mitigate your web server against exploitation by the Apache Range Header Denial of Service vulnerability and the killapache exploit, below is the mitigation steps that worked best for me.

Ubuntu's Apache 2 implementation utilizes httpd.conf for user specific server configuration changes. The mitigation suggestion from the Apache Software Foundation that had the most favorable impact was scrubbing the Range Header if an incoming request contains more than 5 ranges within that specific request. Please note that this fix may not help with future versions of the exploit.

The workaround makes use of mod_headers, which, on a stock ubuntu server apache2 installation, is not enabled. You can enable it using the command line:

sudo a2enmod headers

Once that is complete, modify your servers httpd.conf and add the following directives:

SetEnvIf Range (?:,.*?){5,5} bad-range=1
RequestHeader unset Range env=bad-range

If you want to enable logging of hosts sending you those range requests, modify the configuration file for your virtual server—if you add it to the httpd.conf, the log file will get created but nothing will get logged. For example, if you are using the instance, modify the /etc/apache2/sites-available/default configuration file and add the following line somewhere that makes sense:

CustomLog /var/log/apache2/range-CVE-2011-3192.log common env=bad-range

That's all you need to do. Pretty straightforward workaround but hopefully a more formal fix will be made available by the Ubuntu Server team soon.