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: <Pine.LNX.4.21.0701050109090.22480-100000@linuxbox.org>
Date: Fri, 5 Jan 2007 01:11:51 -0600 (CST)
From: Gadi Evron <ge@...uxbox.org>
To: "William A. Rowe, Jr." <wrowe@...e-clan.net>
Cc: Michal Zalewski <lcamtuf@...ne.ids.pl>,
	bugtraq@...urityfocus.com, full-disclosure@...sys.com
Subject: Re: a cheesy Apache / IIS DoS vuln (+a question)

On Wed, 3 Jan 2007, William A. Rowe, Jr. wrote:
> 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.

Wrong. Any vulnerability, no matter how many others are out there or how
unlikely, is indeed a vulnerability.

As one of the people leading the battle againt what you refer to as
"massively parallel DDoS infrastructures", I can tell you I am almost
inclined to giggle here.

Is all you are saying: "YES but mine is better?"

	Gadi.