[21813] in bugtraq
FIN_WAIT_1 DoS: Why the vulnerability still exists?
daemon@ATHENA.MIT.EDU (Manas Garg)
Tue Jul 24 14:41:32 2001
Date: Tue, 24 Jul 2001 20:48:07 +0530
From: Manas Garg <mls@chakpak.net>
To: bugtraq@securityfocus.com
Message-ID: <20010724204807.A432@cygsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
I was just playing around with TCP when it striked me how a FIN_WAIT_1 DoS
attack can easily bring down a host (especially the ones running HTTP Server).
Because I discovered that it has already been reported, I am not writing a
complete description. Stanislav Shalunov has described it fairly well and
following is one of the locations where what he wrote can be found:
http://security-archive.merton.ox.ac.uk/bugtraq-200004/0156.html
I used this method to attack a few Operating Systems (that I had access to) and
following are the results:
Linux (2.4.4): kswapd starts taking 99% CPU and refuses to relinquish the CPU.
Can't do practically anything with the machine and the machine
has to be reset.
NetBSD (1.5) : Throws a warning that it has run out of NMBCLUSTERS and doesn't
let the user do practically anything including killing those
connections. Has to be reset.
FreeBSD (3.4): Throws a warning that it has run out of NMBCLUSTERS and
graciously reboots without consulting the user.
Solaris (2.8): Well, it silently discarded the old connections to keep the
number of connections to 450 (approximately). Didn't check the
RAM and swap on this machine but what matters is that it was
taking some action to avoid a FIN_WAIT_1 DoS attack.
Wanted to check with Windoze, OpenBSD and FreeBSD (4.3) also but ...
I was wondering:
1. Why isn't FIN_WAIT_1 DoS attack is much known or much documented or
much used (compared to others)? Because I found it very efficient and
couldn't see why a DDoS attack would DoS a site with huge data
transfers rather than this method (and that too always).
2. Is there a particular reason that this vulnerability still exists in
these Opearting Systems? I can't believe that compliance to the
protocol is _the_ reason for not fixing this vulnerability.
--manas
