bugtraq - a cheesy Apache / IIS DoS vuln (+a question)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date: Thu, 4 Jan 2007 00:27:11 +0100 (CET)
From: Michal Zalewski <lcamtuf@...ne.ids.pl>
To: bugtraq@...urityfocus.com
Cc: full-disclosure@...sys.com
Subject: 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