From dev-return-72256-apmail-httpd-dev-archive=httpd.apache.org@httpd.apache.org Wed Aug 24 08:06:45 2011 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 A36A68044 for ; Wed, 24 Aug 2011 08:06:45 +0000 (UTC) Received: (qmail 81744 invoked by uid 500); 24 Aug 2011 08:06:44 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 81117 invoked by uid 500); 24 Aug 2011 08:06:35 -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 81095 invoked by uid 99); 24 Aug 2011 08:06:30 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 Aug 2011 08:06:30 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [195.232.224.73] (HELO mailout04.vodafone.com) (195.232.224.73) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 Aug 2011 08:06:19 +0000 Received: from mailint04 (localhost [127.0.0.1]) by mailout04 (Postfix) with ESMTP id D170213270E for ; Wed, 24 Aug 2011 10:05:58 +0200 (CEST) Received: from avoexs01.internal.vodafone.com (unknown [145.230.4.134]) by mailint04 (Postfix) with ESMTP id C534A13253A for ; Wed, 24 Aug 2011 10:05:58 +0200 (CEST) Received: from VF-MBX11.internal.vodafone.com ([145.230.5.20]) by avoexs01.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 24 Aug 2011 10:05:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: DoS with mod_deflate & range requests Date: Wed, 24 Aug 2011 10:05:58 +0200 Message-ID: In-Reply-To: <201108240028.03308.sf@sfritsch.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DoS with mod_deflate & range requests Thread-Index: Acxh5AdoTR5a2RQ5Tm+MmHc9N0Uf1wAT7Fyw References: <4E541CE5.1080608@rowe-clan.net> <201108240028.03308.sf@sfritsch.de> From: =?iso-8859-1?Q?=22Pl=FCm=2C_R=FCdiger=2C_VF-Group=22?= To: X-OriginalArrivalTime: 24 Aug 2011 08:05:58.0142 (UTC) FILETIME=[A7E361E0:01CC6234] X-Virus-Checked: Checked by ClamAV on apache.org =20 > -----Original Message----- > From: Stefan Fritsch =20 > Sent: Mittwoch, 24. August 2011 00:28 > To: dev@httpd.apache.org > Subject: Re: DoS with mod_deflate & range requests >=20 > On Tuesday 23 August 2011, William A. Rowe Jr. wrote: > > On 8/23/2011 4:00 PM, Greg Ames wrote: > > > On Tue, Aug 23, 2011 at 3:32 PM, William A. Rowe Jr. wrote: > > > I suggest we should be parsing and reassembling the list > > > before we start the bucket logic. > > > =20 > > > I propose we satisfy range requests in the only sensible > > > manner, returning the ranges in sequence, > > >=20 > > > yeah, overlapping ranges should be merged up front. That ought to > > > completely fix the issue. > >=20 > > So the only remaining question; are we free to reorder them into > > sequence? >=20 > Good point. I haven't seen anything in the RFC about that. I guess=20 > that there are at least some clients that will be broken by that. >=20 > Nevertheless, I have done a first try at a patch. The necessary=20 > modification to only merge and not reorder should be small. I have=20 > done only limited testing, so there are probably some bugs. There are=20 > no tests with multiple ranges in the test-framework, yet. >=20 > > Even in the most pedantic case, I believe that the total array > > shouldn't ever exceed 1024, because in those cases a large number > > of the acceptable expected ranges should be in the nnn-nnn, > > format, or 8 characters long, out of our MAX_LINE_LENGTH of some > > 8190. If we argue that asking for single bytes is simply wrong, > > we should probably allocate some 16 ranges and grow the list by a > > power of four, resulting in a max of some 4 allocs and maximum > > memory consumption of less than 64k per request. >=20 > Just counting the commas in the header line seems acceptable=20 > to me. In=20 > any case, single byte ranges are explicitly mentioned in the RFC as=20 > example, so we probably should not disallow those. Patch looks good, but some comments: As far as I can see the following range request would not get merged: Range: bytes=3D0-0,1-1,2-2 into a 0-2 range as need_sort would remain 0. OTOH Range: bytes=3D0-0,0-1,1-2 would get get merged into a 0-2 range. Using boundary and !boundary in the later if statements to decide = whether a request is multi range or single range is IMHO bad as boundary is set based on = the old number ranges and not based on the number of merged ranges. So multiple ranges = in the beginning might get merged to a single range in the end. Regards R=FCdiger