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 for Android: free password hash cracker in your pocket

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

Message-ID: <Pine.LNX.4.58.0701041023560.22436@dione>
Date: Thu, 4 Jan 2007 10:55:49 +0100 (CET)
From: Michal Zalewski <lcamtuf@...ne.ids.pl>
To: "William A. Rowe, Jr." <wrowe@...e-clan.net>
Cc: bugtraq@...urityfocus.com
Subject: Re: a cheesy Apache / IIS DoS vuln (+a question)

On Thu, 4 Jan 2007, William A. Rowe, Jr. wrote:

> On the matter of your 1GB window (which is, again, the real issue), you have
> any examples of a kernel that permits that large a sliding window buffer by
> default

No, I simply mentioned the hypothetical maximum; common configurations for
high-performance applications call for configs from several megs upward,
and this is increasing with the bandwidth available to consumers.

William, again, this is not a critical issue; I did mention that, and if
it were, I wouldn't report it that way. There were two distinct problems
mentioned, and I probably shouldn't mix them the way I did:

  1) A single HTTP request can be used to return 5000x the largest file on
     a server regardless of web admin's intent. This is not a common
     knowledge, and yes, it is worth reporting, because it can be used to
     make a DoS or zombie-based DDoS attacks more painful than usual,
     by considerably improving the ratio of bandwidth required to initiate
     an attack to the traffic generated at victim's expense (compared to
     known attacks using simultaneous HTTP connections, keep-alives, etc).

  2) Theoretical window size limits and commonly implemented settings do
     have a side effect of making such attacks more feasible for
     attackers with a very limited bandwidth available. There's probably
     not that much difference between a 10 MB and a 1 GB window size,
     anyway: the attacker can establish a dial-up connection to ISP A,
     initiate a series of 5000x requests with 10 MB window size, then
     reconnect to ISP B, and continue to slowly and calmly spoof ACKs
     as coming from his previous IP to the attacked server (he knows
     all the sequence numbers). It would take 40 bytes to generate next
     10 MB of traffic within an established connection, so it still
     sounds like fun for a guy who has a 4 kB/s link. And that's why I
     asked whether there was any research done on such issues.

/mz