Subject: Overlapping ranges

From: V13 <[email-masked]>
Date: Fri, 10 Oct 2008 20:15:50 +0300

Hello there,

While you are at the ranges thing, I'd like to request/suggest/ask that 
requests with overlapping ranges be prohibited or at least deprecated.

Allowing overlapping ranges permits the client side to request more data than 
the largest file available at the server side. It is trivial to construct a 
100MB file request from 200 overlapping partial requests of a 500K file. This 
allows the TCP optimistic ACK attack [1] to be performed on web servers all 
over the world.

I'm (we're) currently writting this as a paper and I'll post it here too if 
you like, when it is finished but until then just take my word. As far as I 
know this is the only known way that one can force the server side to 
transmit at rates much higher than the disk I/O rate (because requesting the 
same range takes advantage of the disk cache). When combined with persistent 
connections it also the only known way to infinitely request data from the 
server side. This gives enough time to TCP to reach its maximum transmission 
rate and keep that rate.

For the record, we were able to force a web server to continuously transmit at 
900Mbps over the Internet for more than 5 minutes (until interrupted) using 
just a 100Mbytes file, overlapping ranges and a persistent HTTP connection. 
Without overlapping ranges this wouldn't be possible.

So, since there is no sane usage of overlapping ranges (as far as I can tell), 
they should be either forbidden or have a security note added (perhaps with a 
pointer to the paper - if/when published - later). 

[1] http://www.mail-archive.com/linux-net%40vger.kernel.org/msg01053.html

---

From: Julian Reschke <[email-masked]>
Date: Sat, 11 Oct 2008 12:32:27 +0200

V13 wrote:
> ...

I agree that this is a nice DOS scenario, but wouldn't it be possible to 
do the same just with a bunch of concurrent, repeating GET requests on 
the same URI?

BR, Julian

---

From: Stefanos Harhalakis <[email-masked]>
Date: Sun, 12 Oct 2008 21:21:43 +0300

Hello Julian,

On Saturday 11 October 2008, Julian Reschke wrote:
> V13 wrote:
> > Allowing overlapping ranges permits the client side to request more data
> > than the largest file available at the server side. It is trivial to
> > construct a 100MB file request from 200 overlapping partial requests of a
> > 500K file. This allows the TCP optimistic ACK attack [1] to be performed
> > on web servers all over the world.
>

Indeed, repeated GET requests will have the same result but they will be a bit 
less robust. For every repeated request that the client side transmits there 
is a (not so small) possibility of the request being lost. If this problem is 
of size X then it is practically multiplied by the number of repeated ranges 
that the client side may request.

Also, I can't think of a method for avoiding repeated requests without making 
the server side somehow vulnerable to a connection with 1 million 1-byte 
requests, unless there is a maximum request limit.

p.s.1 This attack also affects proxies.
p.s.2 IIS seems to limit the number of ranges per request to ~5 (I don't 
remember the exact number).

---

From: Yves Lafon <[email-masked]>
Date: Mon, 13 Oct 2008 08:12:18 -0400 (EDT)

> that the client side may request.

Some servers are limiting the number of requests per connections (in 
pipelining mode or not), others try to detect abuse on the whole server, 
both are counter-measures not present in the HTTP RFC but part of 
implementation experience.

In the same vein, refusing overlapping range request that would be bigger 
than exporting the whole document (and serving the document instead) seems 
to be a sane implementation choice, but the spec shouldn't cover all those 
corner cases, IMHO.

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

---

From: "Brian Smith" <[email-masked]>
Date: Mon, 13 Oct 2008 09:53:08 -0500

Yves Lafon wrote:
> In the same vein, refusing overlapping range request that 
> would be bigger than exporting the whole document (and
> serving the document instead) seems to be a sane
> implementation choice, but the spec shouldn't cover all
> those corner cases, IMHO.

I agree that the specification doesn't need to be ammended to allow the
server to refuse these requests since the server can already refuse them.
However, it should be mentioned in the security considerations.

---

From: Yves Lafon <[email-masked]>
Date: Tue, 14 Oct 2008 10:37:08 -0400 (EDT)

> However, it should be mentioned in the security considerations.

Agreed. and it's the case for all known security issues.

         ~~Yves