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]
Date: Fri, 5 Jan 2007 01:11:51 -0600 (CST)
From: Gadi Evron <>
To: "William A. Rowe, Jr." <>
Cc: Michal Zalewski <>,,
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?"


Powered by blists - more mailing lists