httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: DoS with mod_deflate & range requests
Date Wed, 24 Aug 2011 21:00:34 GMT
On 8/24/2011 3:45 PM, Dirk-WIllem van Gulik wrote:
> 
> On 24 Aug 2011, at 21:39, Greg Ames wrote:
> 
>> On Wed, Aug 24, 2011 at 3:19 PM, Jim Jagielski <jim@jagunet.com
>> <mailto:jim@jagunet.com>> wrote:
>>
>>
>>     >
>>     > If we only merge adjacent ascending ranges, then it seems like an attacker
could
>>     just craft a header where the ranges jump around and dodge our fix.
>>     >
>>
>>     I think no matter what, we should still have some sort of
>>     upper limit on the number of range-sets we accept… after all,
>>     merge doesn't prevent jumping around ;)
>>
>>
>> The problem I have with the upper limit on the number of range sets is the use case
>> someone posted for JPEG2000 streaming.  That has a lot of range sets but is completely
>> legit.  However, the ranges are in ascending order and don't overlap.  Maybe we could
>> count overlaps and/or non-ascending order ranges and fall back to 200 + the whole
object
>> if it exceeds a limit.
> 
> Right - and the other two use cases in the wild are
> 
> -PDF readers - which fetch something at the start in RQ 1 and then the index form the
end
> - and then quick looks images for each page and title pages. I've seen them do a second
> and 3rd request with many 10's of ranges.
> 
> -Some of the streaming video (semi/pro) video editors - which fetch a bunch of i-Frames
> and do clever skip over stuff. Not in the high tens; but 10-15 ranges common.
> 
> -Likewise for very clever MXF professional editing equipment - the largest case (yup
- it
> did crash my server) tried to fetch over 2000 ranges :)
> 
> So I think we really should endeavor to allow 50 to a few 100 of them. Or at the very
> least - make it a config option to cut off below 50 or so.

At least, after 256 ranges or so, fall back to a 200 response in lieu of
a 400/416 response.


Mime
View raw message