FIN_WAIT_1 DoS: Why the vulnerability still exists?

From: Manas Garg (mlsat_private)
Date: Tue Jul 24 2001 - 08:18:07 PDT

  • Next message: Josh Brandt: "Re: telnetd exploit code"

    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
    



    This archive was generated by hypermail 2b30 : Tue Jul 24 2001 - 11:40:21 PDT