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