On 26/08/11 8:52 PM, Carlos Alberto Lopez Perez wrote:
On 26/08/11 11:17, Christian Hammers wrote:
Hallo
Word is spreading that "Request-Range:" seems to be a synonym to "Range:" and
is similar vulnerable but not covered by the config snippets that were
proposed yesterday. So Gentlemen, patch again! :-(
Confirmed!.
Just modified the suggest solution[1] adding an [OR] (and nocase) for
also matching for request-range
RewriteEngine on
RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$) [NC,OR]
RewriteCond %{HTTP:request-range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$) [NC]
RewriteRule .* - [F]
[1] https://lwn.net/Articles/456268/
Hello,
I'm curious as to why you suggest option 2 over option 1 from the Apache
advisory? My guess is that it is compatible with version 1.3 and 2.x and
that is has stronger enforcement of the syntax (by requiring ^bytes=)
rather than just 5 comma separated fields. Would the following be the
equivalent update to option 1:
# Drop the Range header when more than 5 ranges.
# CVE-2011-3192
SetEnvIf Range (,.*?){5,} bad-range=1
SetEnvIf Request-Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
RequestHeader unset Request-Range env=bad-range
# optional logging.
CustomLog /var/log/apache2/range-CVE-2011-3192.log common env=bad-range
I've put that into /etc/apaches/conf.d/CVE-2011-3192
I appreciate that it clobbers both headers if either match but that's ok
for me. If either match I'd be happier to drop the connection but I
don't want to touch every virtualhost config and Rewrite rules scare me too.
Best regards,
LB
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e5781f4.1030...@fastmail.fm
