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: Wed, 03 Jan 2007 23:35:37 -0600
From: "William A. Rowe, Jr." <>
To: Michal Zalewski <>
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

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.

Powered by blists - more mailing lists