a cheesy Apache / IIS DoS vuln (+a question)
I feel silly for reporting this, but I couldn't help but notice that
Apache and IIS both have a bizarro implementation of HTTP/1.1 "Range"
header functionality (as defined by RFC 2616). Their implementations allow
the same fragment of a file to be requested an arbitrary number of times,
and each redundant part to be received separately in a separate
multipart/byteranges envelope.
Combined with the functionality of window scaling (as per RFC 1323), it is
my impression that a lone, short request can be used to trick the server
into firing gigabytes of bogus data into the void, regardless of the
server file size, connection count, or keep-alive request number limits
implemented by the administrator. Whoops?
Since there are easier tools to (D)DoS a service, and since nothing about
this attack is particularly innovative, I'll just describe what's on my
mind... let's say that http://example.com/foo.html is a medium-size static
file we found on the server (something on the order of 300 kB for Apache
and 150 kB for IIS is optimal). An attack would then look roughly the
following way:
1) Connect to the server (as many times as allowed by the remote party
or deemed appropriate for the purpose of this demonstration),
2) Negotiate a high TCP window size for each of the connections (1 GB
should be doable),
3) Send a partial request as follows for each of the connections:
GET /foo.html HTTP/1.1
Host: example.com
Range: bytes=0-,0-,0-,0-,0-... (up to 8 kB for Apache, 16 kB for IIS)
Each "0-" would generate a separate multipart/byteranges containing
the entire file (bytes from 0 'til EOF).
4) Send a closing newline within each of the connections to commit
the request,
5) Silently drop the connections, possibly re-connect to dial-up / DSL
to duck the responses that would keep pouring at full speed until
TCP window size is exhausted or an ISP-level non-delivery /
congestion control mechanism kicks in (and isn't filtered out
down the route).
This should cause the server to send gigabytes of data, with only a
minimal bandwidth expense on the attacker's end.
Well, that's the story.
This isn't the only "fire-and-run-away" attack that seems to be made much
more feasible with the help of window scaling (by making it more tempting
for the attacker to request tons of data and then go off-line and never
acknowledge it). Was there any work done on that topic? Can't Google
anything up.
(An example would be an "old-fashioned" attack on a server that happens
to host multi-gigabyte ISO files or movies - simply request them
many times and let window scaling do the rest... of course, most
high-profile sites are smart enough to host static HTML and basic layout
elements separately from such bandwidth-intensive and non-essential
content, so it still makes sense to take note of "Range" behavior).
/mz