Bug#663723: Critical memory leak with mod_rewrite in apache2 using german umlauts
Package: apache2 Version: 2.2.16-6+squeeze6 Severity: serious Tags: security Hello, I noticed on a customers server, that apache periodical crashes the whole system by using the whole available memory until it swaps away. I have found out that this is caused by a crafted .htaccess where german umlauts handled in a wrong way. I have tested it on: * Lenny amd64 with apache2-prefork * Lenny i386 with apache2-prefork * Squeeze amd64 with apache2-prefork * Squeeze i386 with apache2-prefork * Lenny amd64 with apache2-worker * Lenny i386 with apache2-worker * Squeeze amd64 with apache2-worker * Squeeze i386 with apache2-worker It is reproduced easily on all systems (locale of all systems: de_DE.UTF-8) Ways to reproduce: # apt-get install apache2 # a2enmod rewrite Put the following code to e.g. /var/www/.htaccess: RewriteEngine on RewriteBase / RewriteRule ^(.*)\xC3\x84(.*)$ $1Ä$2 [N,E=utf8_fixed:1] RewriteRule ^(.*)\xC3\xA4(.*)$ $1ä$2 [N,E=utf8_fixed:1] RewriteRule ^(.*)\xC3\x96(.*)$ $1Ö$2 [N,E=utf8_fixed:1] RewriteRule ^(.*)\xC3\xB6(.*)$ $1ö$2 [N,E=utf8_fixed:1] RewriteRule ^(.*)\xC3\x9C(.*)$ $1Ü$2 [N,E=utf8_fixed:1] RewriteRule ^(.*)\xC3\xBC(.*)$ $1ü$2 [N,E=utf8_fixed:1] RewriteRule ^(.*)\xC3\x9F(.*)$ $1ß$2 [N,E=utf8_fixed:1] Go to your browser and open: http://localhost/Parf%C3%BCmerie Now the server runs out of memory very fast! This is especialy a big problem for shared hosters with mod_rewrite enabled (most vhosts require them today) where users could put their own .htaccess to the documentroot -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org */ -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f5f6670.6090...@debian.org
Bug#663723: Critical memory leak with mod_rewrite in apache2 using german umlauts
severity 663723 wishlist tags 663723 -security retitle 663723 apache2 does not prevent DoS through .htaccess files thanks On Tuesday 13 March 2012, Patrick Matthäi wrote: I noticed on a customers server, that apache periodical crashes the whole system by using the whole available memory until it swaps away. RewriteEngine on RewriteBase / RewriteRule ^(.*)\xC3\x84(.*)$ $1Ä$2 [N,E=utf8_fixed:1] The problem is not the special character but that this regular expression has quadratic complexity in the string length. Using (.*?) instead of (.*) everywhere will likely fix it. This is a general problem when using regular expressions. And being allowed to use .htaccess means having access to regular expressions. Now the server runs out of memory very fast! This is especialy a big problem for shared hosters with mod_rewrite enabled (most vhosts require them today) where users could put their own .htaccess to the documentroot While I don't deny that this is a problem for some use cases, it is a fact that the .htaccess mechanism has not been designed with limiting local DoS attacks in mind. There are many ways to cause a DoS with crafted .htaccess files. Some of these cannot be fixed without breaking compatibility, i.e. not within 2.2.x or 2.4.x. Therefore, picking out a few of these issues and fixing them in Debian does not make any sense. If you use prefork, you can work around this by adding suitable ulimit calls in /etc/apache2/envvars. Upstream does not consider these issues security relevant, either: http://mail-archives.apache.org/mod_mbox/httpd- dev/20.mbox/%3c4ec6de56.9020...@rowe-clan.net%3E -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201203132015.17642...@sfritsch.de
Processed: Re: Bug#663723: Critical memory leak with mod_rewrite in apache2 using german umlauts
Processing commands for cont...@bugs.debian.org: severity 663723 wishlist Bug #663723 [apache2] Critical memory leak with mod_rewrite in apache2 using german umlauts Severity set to 'wishlist' from 'serious' tags 663723 -security Bug #663723 [apache2] Critical memory leak with mod_rewrite in apache2 using german umlauts Removed tag(s) security. retitle 663723 apache2 does not prevent DoS through .htaccess files Bug #663723 [apache2] Critical memory leak with mod_rewrite in apache2 using german umlauts Changed Bug title to 'apache2 does not prevent DoS through .htaccess files' from 'Critical memory leak with mod_rewrite in apache2 using german umlauts' thanks Stopping processing here. Please contact me if you need assistance. -- 663723: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663723 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.133166618625058.transcr...@bugs.debian.org
Bug#663723: Critical memory leak with mod_rewrite in apache2 using german umlauts
Am 13.03.2012 20:15, schrieb Stefan Fritsch: RewriteEngine on RewriteBase / RewriteRule ^(.*)\xC3\x84(.*)$ $1Ä$2 [N,E=utf8_fixed:1] The problem is not the special character but that this regular expression has quadratic complexity in the string length. Using (.*?) instead of (.*) everywhere will likely fix it. This is a general problem when using regular expressions. And being allowed to use .htaccess means having access to regular expressions. While I don't deny that this is a problem for some use cases, it is a fact that the .htaccess mechanism has not been designed with limiting local DoS attacks in mind. There are many ways to cause a DoS with crafted .htaccess files. Some of these cannot be fixed without breaking compatibility, i.e. not within 2.2.x or 2.4.x. Therefore, picking out a few of these issues and fixing them in Debian does not make any sense. If you use prefork, you can work around this by adding suitable ulimit calls in /etc/apache2/envvars. Upstream does not consider these issues security relevant, either: http://mail-archives.apache.org/mod_mbox/httpd- dev/20.mbox/%3c4ec6de56.9020...@rowe-clan.net%3E Thanks for your explanation, I thought the problem is more about the special char handling (couldn't test so much, yet). If the regular expression is wrong, okay, but what is about e.g. the RedirectLimit? This also could cause server problems with crafted configurations, but there is internal apache limit available. In this case an shared hosting server (~ 300 customers) was affected and crashed several times about months and we had to introduce workarounds (killer scripts) to prevent the server to crash at all; debugging was quite hard aka impossible. Here upstream should introduce something which prevents apache to crash itself and the whole server. Since this is IMHO opinion a DoS - against the whole server, not only the service, which requires local user access (customer uploading his .htaccess) - it is security important, severity important okay, but not wishlist.. Regarding the mail from apache-dev: How is resource abuse defined? IMHO if the customer uploads a htaccess and after that e.g the cpu load + response times are higher, okay... pure configuration issue But adding a few lines to crash the whole server? This is not a resource abuse. This is something like: - a file traversal issue where a victim could read out /etc/passwd is no security issue - but maybe reading out /etc/shadow From my Debian POV it is an security issue, also if upstream don't want it.. -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org */ signature.asc Description: OpenPGP digital signature
Bug#663723: Critical memory leak with mod_rewrite in apache2 using german umlauts
On Tuesday 13 March 2012, Patrick Matthäi wrote: If the regular expression is wrong, okay, but what is about e.g. the RedirectLimit? This also could cause server problems with crafted configurations, but there is internal apache limit available. You mean LimitInternalRecursion? That is to protect from misconfigurations. In the same way, it would be nice to have a protection from runaway regexes. PCRE has a way to limit its recursion, but no one has changed apache to use that, yet. And it would be considerable work to do this change while avoiding unintended side effects. In this case an shared hosting server (~ 300 customers) was affected and crashed several times about months and we had to introduce workarounds (killer scripts) to prevent the server to crash at all; debugging was quite hard aka impossible. Here upstream should introduce something which prevents apache to crash itself and the whole server. Since this is IMHO opinion a DoS - against the whole server, not only the service, which requires local user access (customer uploading his .htaccess) - it is security important, severity important okay, but not wishlist.. Regarding the mail from apache-dev: How is resource abuse defined? IMHO if the customer uploads a htaccess and after that e.g the cpu load + response times are higher, okay... pure configuration issue But adding a few lines to crash the whole server? This is not a resource abuse. There is no clear dividing line between the two. What is only a slightly increased memory usage on a big server with 16GB of RAM will cause Linux's OOM-killer to wreak havoc on a small virtual server with 128MB RAM. Apache does not try to adjust its resource usage to the size of the used server (again, a missing feature, not a security defect). This tuning is left to the administrator. You can prevent the whole server from being affected by setting suitable MaxClients and memory limits. You could also change oom_adj on the apache processes, to ensure that apache is killed and not other processes. -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201203132225.57829...@sfritsch.de
