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]

Date: Thu, 04 Jan 2007 12:45:35 +0100
From: Pieter de Boer <pieter@...darkside.nl>
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:
>   2) Negotiate a high TCP window size for each of the connections (1 GB
>      should be doable),
>   
Just zooming in on one detail of your e-mail. While you could set your 
own TCP receive window to 1GB, you obviously can't set the sender's send 
window to 1GB if it doesn't want to.

For instance, FreeBSD by default has TCP send buffers set to 32KB. It 
does not (apart from recent work) do dynamic buffer sizing. 32KB is all 
you get. Sysadmins probably raise this value, but, especially with large 
amounts of connections, it can't be set too high or mbufs will run out. 
I'd guess people wouldn't set it to much more than 1MB or such.

Linux does do dynamic buffer sizing but also has some limits set. On a 
recent Ubuntu (desktop), the sysctl net.ipv4.tcp_wmem is set to '4096 
16384 131072'. The last parameter is the maximum amount of buffer space 
reserved for sending, per TCP socket. Again, sysadmins probably raise 
this value in practice.

Concluding, I think your suggested attack might work, but it would need 
a braindead configuration on the sender's end to be really effective. 
It's probably easier just to send some ACKs now and then..

-- 
Pieter