You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by gw...@fscinternet.com on 2002/08/13 17:51:59 UTC

Apache dies on large error_log (possible remote DoS)

Bug in Apache 2.0.40 on Linux (possibly others): When error_log reaches 
2.0 GB in size, each httpd process (including the parent) will die 
without warning on it's next write to error_log.

An attacker flooding the server with large invalid requests using 
Keep-Alives, can fill error_log at about a 1:1 ratio to the number of 
bytes transmitted (including TCP/IP overhead). A single attacker with a 
fast cable modem could bring down an Apache server in an evening using 
this method.

Note:  An email reporting this problem in more detail was sent to 
security@apache.org a week ago without response.

Graham Wiseman
gwiseman@fscinternet.com


Re: Apache dies on large error_log (possible remote DoS)

Posted by Justin Erenkrantz <je...@apache.org>.
On Tue, Aug 13, 2002 at 11:54:14AM -0400, Cliff Woolley wrote:
> This has always been the case for both Apache 2.0 and 1.3 and is a
> well-known issue.  It's up to the administrator to have appropriate log
> rotation and monitoring in place, as there's not much we can really do
> about this from within the server itself.

We *could* teach httpd about LARGEFILE so if the OS supports it
we can have large logs, but, the essential problem still remains -
you can easily get the log file to eat up all disk space.  -- justin

Re: Apache dies on large error_log (possible remote DoS)

Posted by Cliff Woolley <jw...@virginia.edu>.
On Tue, 13 Aug 2002 gwiseman@fscinternet.com wrote:

> Bug in Apache 2.0.40 on Linux (possibly others): When error_log reaches
> 2.0 GB in size, each httpd process (including the parent) will die
> without warning on it's next write to error_log.

This has always been the case for both Apache 2.0 and 1.3 and is a
well-known issue.  It's up to the administrator to have appropriate log
rotation and monitoring in place, as there's not much we can really do
about this from within the server itself.

--Cliff