Return-Path: X-Original-To: apmail-httpd-dev-archive@www.apache.org Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0902D8352 for ; Wed, 24 Aug 2011 20:46:30 +0000 (UTC) Received: (qmail 55591 invoked by uid 500); 24 Aug 2011 20:46:29 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 55532 invoked by uid 500); 24 Aug 2011 20:46:28 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 55524 invoked by uid 99); 24 Aug 2011 20:46:28 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 Aug 2011 20:46:28 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of dirkx@webweaving.org designates 178.18.23.51 as permitted sender) Received: from [178.18.23.51] (HELO pikmeer.webweaving.org) (178.18.23.51) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 Aug 2011 20:46:22 +0000 Received: from pappamoem.home (host81-159-211-94.range81-159.btcentralplus.com [81.159.211.94]) (authenticated bits=0) by pikmeer.webweaving.org (8.14.4/8.14.4) with ESMTP id p7OKjslH076523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 24 Aug 2011 20:45:55 GMT (envelope-from dirkx@webweaving.org) From: Dirk-WIllem van Gulik Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_35B1C86F-F0B5-4CC9-B4EE-67B7BDB425D6" Subject: Re: DoS with mod_deflate & range requests Date: Wed, 24 Aug 2011 21:45:59 +0100 In-Reply-To: To: dev@httpd.apache.org References: <4E53EEEF.2060409@rowe-clan.net> <201108232049.58021.sf@sfritsch.de> <4E540062.4040903@rowe-clan.net> <4E541CE5.1080608@rowe-clan.net> <20110824153559.GA24702@nebula.c8h10n4o2.org.uk> <71A86EB1-CCBA-40E9-A853-02C2CC3400A6@bbc.co.uk> <4E55253C.3050905@rowe-clan.net> <08F45893-EBFE-4C35-BE1E-37F2189D194D@jaguNET.com> Message-Id: X-Mailer: Apple Mail (2.1244.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (pikmeer.webweaving.org [178.18.23.51]); Wed, 24 Aug 2011 20:45:55 +0000 (UTC) --Apple-Mail=_35B1C86F-F0B5-4CC9-B4EE-67B7BDB425D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 24 Aug 2011, at 21:39, Greg Ames wrote: > On Wed, Aug 24, 2011 at 3:19 PM, Jim Jagielski = wrote: >=20 > > > > 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. > > >=20 > I think no matter what, we should still have some sort of > upper limit on the number of range-sets we accept=85 after all, > merge doesn't prevent jumping around ;) >=20 >=20 > 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. Dw.= --Apple-Mail=_35B1C86F-F0B5-4CC9-B4EE-67B7BDB425D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Wed, = Aug 24, 2011 at 3:19 PM, Jim Jagielski <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=85 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.

Dw.
= --Apple-Mail=_35B1C86F-F0B5-4CC9-B4EE-67B7BDB425D6--