You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Stefan Fritsch <sf...@sfritsch.de> on 2009/06/28 20:20:20 UTC

mod_deflate DoS

Hi,

we have received a bug report [1] that a DoS is possible with 
mod_deflate since it does not stop to compress large files even after 
the network connection has been closed. This allows to use large 
amounts of CPU if there is a largish (>10 MB) file available that has 
mod_deflate enabled.

An exploit is as easy as 

for a in $(seq 1 100) ; do
curl -H "Accept-Encoding: gzip" -is  http://url.to/large/file.txt | 
head -1  ; done

François Guerraz, the bug submitter, also suggested a patch:

--- mod_deflate.c       2008-01-04 15:23:50.000000000 +0100
+++ mod_deflate.c.new   2009-06-26 16:50:36.000000000 +0200
@@ -691,6 +691,10 @@
             continue;
         }

+       if (r->connection->aborted) {
+            return APR_ECONNABORTED;
+        }
+
         /* read */
         apr_bucket_read(e, &data, &len, APR_BLOCK_READ);

This greatly reduces the problem. But even with it, quite a bit of 
data is compressed (maybe determined by APR_MMAP_LIMIT == 4MB?).

Cheers,
Stefan

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534712


Re: mod_deflate DoS

Posted by Joe Orton <jo...@redhat.com>.
On Sun, Jun 28, 2009 at 08:20:20PM +0200, Stefan Fritsch wrote:
> we have received a bug report [1] that a DoS is possible with 
> mod_deflate since it does not stop to compress large files even after 
> the network connection has been closed. This allows to use large 
> amounts of CPU if there is a largish (>10 MB) file available that has 
> mod_deflate enabled.

Thanks for posting the report.  This issue has been assigned 
CVE-2009-1891.

On the security list, Ruediger suggested these fixes, which I've 
proposed for inclusion in 2.2.x:

http://people.apache.org/~jorton/CVE-2009-1891.1.diff
http://people.apache.org/~jorton/CVE-2009-1891.2.diff

along with a third fix which concerned event MPM write completion - 
AFAICT that is not relevant on the 2.2.x branch.

Regards, Joe