Bugtraq mailing list archives

FIN_WAIT_1 DoS: Why the vulnerability still exists?


From: Manas Garg <mls () chakpak net>
Date: Tue, 24 Jul 2001 20:48:07 +0530

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


Current thread: