[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-httpd-dev
Subject:    Re: CVE-2011-3192 and mod_proxy
From:       "Stefan Fritsch" <sf () sfritsch ! de>
Date:       2011-08-30 11:08:11
Message-ID: 00c3859c119f1bba04766053612b2b63.squirrel () www ! sfritsch ! de
[Download RAW message or body]

On Tue, August 30, 2011 12:56, Micha Lenk wrote:
> I've just installed the recent security update (package apache2
> 2.2.16-6+squeeze2) that Debian just released for fixing CVE-2011-3192. I
> made a short test request for a test document with exactly 10 bytes
> length and with a header
>
> Range: bytes=0-4,5-9,0-9
>
> to test whether the patch works as expected.
>
> For content that is not proxied, the security fix seems to fix the
> issue, i.e. the full document is delivered unchunked as a whole.

This is not the important part of the fix. The important part is that
Apache httpd doesn't need lots of memory anymore to process the ranges,
even if there are a lot of them.

> But for content that is proxied via mod_proxy_http, the request
> including the bad Range: header hits the backend server. So, if the
> backend server is also an Apache, which is still vulnerable to
> CVE-2011-3192, it would receive malicious Range headers unfiltered.
>
> Is this intended behavior? Couldn't we filter out bad ranges on proxy
> request too?

Yes, this is the intended behaviour. The Range-header is processed by the
backend server (after all, we don't want to request the whole file from
the backend to just send a few bytes onward to the client). The exploit
would make the backend server explode and not the proxy server. Therefore
you need to patch the backend server and not the proxy. If you want a
filtering solution on the proxy, mod_security is your friend.

> If this is not intended to be fixed, it is maybe a good idea to include
> an explicit hint about this behavior in the security advisory.

That may be a good idea.

> However, the workaround from earlier announcements using following lines
> in the configuration does also work for a proxied request:
>
> # Drop the (Request-)Range header if more than 5 ranges (CVE-2011-3192)
> SetEnvIf Range (,.*?){5} bad-range=1
> RequestHeader unset Range env=bad-range
> SetEnvIf Request-Range (,.*?){5} bad-request-range=1
> RequestHeader unset Request-Range env=bad-request-range

Yes, the workaround really does filtering.

Cheers,
Stefan

[prev in list] [next in list] [prev in thread] [next in thread]