bugtraq - Re: 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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <459C9229.8020609@rowe-clan.net>
Date: Wed, 03 Jan 2007 23:35:37 -0600
From: "William A. Rowe, Jr." <wrowe@...e-clan.net>
To: Michal Zalewski <lcamtuf@...ne.ids.pl>
Cc: bugtraq@...urityfocus.com, full-disclosure@...sys.com
Subject: Re: a cheesy Apache / IIS DoS vuln (+a question)

Michal Zalewski wrote:
> 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.

Batten down the hatches!

>   (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).

Seriously, HTTP pipelining can accomplish EXACTLY the same thing with minimal
pain.  If you have an issue with this behavior, of HTTP, then you have an
issue with the behavior under FTP or a host of other protocols.  And as you
say, simple enough to find some 1.5mb pdf's.  But you expect 1gb window sizes
to actually succeed?

In 95% of the cases that follow your comment above, although the load may
be often be distributed between boxes based on computational intensity, it
is nearly always shoved down the same pipe in the end.

> Combined with the functionality of window scaling (as per RFC 1323)

is exactly where your concern should lay - socket kernel-level control of
unrealistic window scaling, and similar scaling restrictions at the router
layer.

With the host of real issues out there in terms of massively parallel DDoS
infrastructures that abound, this is, as you say, quite a silly report.