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

Powered by blists - more mailing lists