Hi Paweł,

Thanks for taking the time to report this issue.

First off, killapache.pl's testapache() function for whether the host is vulnerable is not very accurate; all it tests is whether apache returns 206 Partial Content when given the byte range of '0-'. In our update, we included the upstream commit 
http://svn.apache.org/viewvc?view=revision&sortby=date&revision=1163833 which returns a 206 on that byte range because debian had a bug report http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639825 of a client breaking when 200 was returned for that exact byte range.

Second, I'm unable to reproduce the difference in behavior that you're seeing when gzip compression is enabled or disabled; with a stock setup, my attempts look like:

  $ dpkg -l apache2-mpm-prefork | tail -1
  ii  apache2-mpm-prefork                  2.2.14-5ubuntu8.6

  $ apache2ctl -t -D DUMP_MODULES  |grep deflate
  apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName
  Syntax OK
   deflate_module (shared)

  # ask for gzip encoding  
  $ nc localhost 80
  HEAD / HTTP/1.1
  Host: localhost
  Range:bytes=0-100
  Accept-Encoding: gzip
  Connection: close
  
  HTTP/1.1 206 Partial Content
  Date: Sat, 03 Sep 2011 00:04:37 GMT
  Server: Apache/2.2.14 (Ubuntu)
  Last-Modified: Wed, 31 Aug 2011 16:56:54 GMT
  ETag: "482db-b1-4abd003eaae6f"
  Accept-Ranges: bytes
  Vary: Accept-Encoding
  Content-Encoding: gzip
  Content-Range: bytes 0-100/146
  Content-Length: 101
  Connection: close
  Content-Type: text/html
  
  # no gzip encoding
  $ nc localhost 80
  HEAD / HTTP/1.1
  Host: localhost
  Range:bytes=0-100
  Connection: close
  
  HTTP/1.1 206 Partial Content
  Date: Sat, 03 Sep 2011 00:05:26 GMT
  Server: Apache/2.2.14 (Ubuntu)
  Last-Modified: Wed, 31 Aug 2011 16:56:54 GMT
  ETag: "482db-b1-4abd003eaae6f"
  Accept-Ranges: bytes
  Content-Length: 101
  Vary: Accept-Encoding
  Content-Range: bytes 0-100/177
  Connection: close
  Content-Type: text/html
  
  # disable gzip encoding
  $ sudo a2dismod deflate
  Module deflate disabled.
  Run '/etc/init.d/apache2 restart' to activate new configuration!
  $ sudo /etc/init.d/apache2 restart
   * Restarting web server apache2
  apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName
   ... waiting apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName
     ...done.
  $ apache2ctl -t -D DUMP_MODULES  |grep deflate
  apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName
  Syntax OK
  
  # ask for gzip encoding; shouldn't get it
  $ nc localhost 80
  HEAD / HTTP/1.1
  Host: localhost
  Range:bytes=0-100
  Accept-Encoding: gzip
  Connection: close
  
  HTTP/1.1 206 Partial Content
  Date: Sat, 03 Sep 2011 00:07:27 GMT
  Server: Apache/2.2.14 (Ubuntu)
  Last-Modified: Wed, 31 Aug 2011 16:56:54 GMT
  ETag: "482db-b1-4abd003eaae6f"
  Accept-Ranges: bytes
  Content-Length: 101
  Content-Range: bytes 0-100/177
  Connection: close
  Content-Type: text/html
  
  # don't ask for gzip encoding
  $ nc localhost 80
  HEAD / HTTP/1.1
  Host: localhost
  Range:bytes=0-100
  Connection: close
  
  HTTP/1.1 206 Partial Content
  Date: Sat, 03 Sep 2011 00:07:45 GMT
  Server: Apache/2.2.14 (Ubuntu)
  Last-Modified: Wed, 31 Aug 2011 16:56:54 GMT
  ETag: "482db-b1-4abd003eaae6f"
  Accept-Ranges: bytes
  Content-Length: 101
  Content-Range: bytes 0-100/177
  Connection: close
  Content-Type: text/html

I do note that in your first connection attempt, the Content-Length and Content-Range fields are not returned at all. Do you have any idea why this might be? What's different about your configuration than the default? Is it possible there's a transparent proxy in between you and the server? Did you put in place any of the mitigation configurations?

Finally, I should point out that the testcases going around (like the one in killapache.pl) are based on symptomatic behavior and aren't a guarantee that a DoS happens. The testcase that I've been using has a byte range request of

  Range:bytes=1-15,10-35,8-9,14-22,0-5,23-

With that request, I get a 206 response with the vulnerable code and a 200 response with the fix applied, regardless of whether gzip compression is enabled or not.

Finally, running the killapache.pl script with the attack function (killapache) enabled, definitely results in a DoS situation with the unpatched packages (top shows the resident memory data of the apache processes ballooning to 25-30MB), while running it against the updated packages does not (apache processes memory usage stays sane). This is also regardless of whether gzip compression is turned on or not.

Any clarification about your configuration that you can provide to help diagnose the behavior you're seeing would be most appreciated. Thanks!