6790850 2001-07-24 20:48 +0530 /46 rader/ Manas Garg <mls@chakpak.net>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-24 20:56 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18300>
Ärende: FIN_WAIT_1 DoS: Why the vulnerability still exists?
------------------------------------------------------------
From: Manas Garg <mls@chakpak.net>
To: bugtraq@securityfocus.com
Message-ID: <20010724204807.A432@cygsoft.com>
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
(6790850) /Manas Garg <mls@chakpak.net>/--(Ombruten)
Kommentar i text 6791020 av stanislav shalunov <shalunov@internet2.edu>
6791020 2001-07-24 15:05 -0400 /39 rader/ stanislav shalunov <shalunov@internet2.edu>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-24 21:54 av Brevbäraren
Extern mottagare: Manas Garg <mls@chakpak.net>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18312>
Kommentar till text 6790850 av Manas Garg <mls@chakpak.net>
Ärende: Re: FIN_WAIT_1 DoS (netkill): Why the vulnerability still exists?
------------------------------------------------------------
From: stanislav shalunov <shalunov@internet2.edu>
To: Manas Garg <mls@chakpak.net>
Cc: bugtraq@securityfocus.com
Message-ID: <87d76qywpl.fsf@cain.internet2.edu>
Manas Garg <mls@chakpak.net> writes:
> 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
This particular archive HTMLizes messages, so it may be inconvenient
to get the code out of there. See
http://www.internet2.edu/~shalunov/netkill/
> 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.
Solaris 2.8 doing something a good news. However, I don't believe
that throwing away the oldest connections is the best strategy here
(I'd rather throw away random connections, with preference to those
that eat a lot of buffer space).
> 2. Is there a particular reason that this vulnerability still exists
> in these Opearting Systems?
Well, it isn't very obvious what to do about it. And breaking the
standard is undesirable. Soemthing has to be done about the spec. Ad
hoc solutions, different for each OS, could easily lead to
unpredictable TCP reliability failures.
--
Stanislav Shalunov http://www.internet2.edu/~shalunov/
Sex is the mathematics urge sublimated. -- M. C. Reed.
(6791020) /stanislav shalunov <shalunov@internet2.edu>/
Kommentar i text 6795936 av Greg A. Woods <woods@weird.com>
6795936 2001-07-24 16:10 -0400 /33 rader/ Greg A. Woods <woods@weird.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-25 21:38 av Brevbäraren
Extern mottagare: stanislav shalunov <shalunov@internet2.edu>
Extern kopiemottagare: bugtraq@securityfocus.com
Externa svar till: woods@weird.com
Mottagare: Bugtraq (import) <18341>
Kommentar till text 6791020 av stanislav shalunov <shalunov@internet2.edu>
Ärende: Re: FIN_WAIT_1 DoS (netkill): Why the vulnerability still exists?
------------------------------------------------------------
From: woods@weird.com (Greg A. Woods)
To: stanislav shalunov <shalunov@internet2.edu>
Cc: bugtraq@securityfocus.com
Message-ID: <20010724201023.628C4DF@proven.weird.com>
[ On , July 24, 2001 at 15:05:10 (-0400), stanislav shalunov wrote: ]
> Subject: Re: FIN_WAIT_1 DoS (netkill): Why the vulnerability still exists?
>
> (I'd rather throw away random connections, with preference to those
> that eat a lot of buffer space).
That seems illogical given the nature of the problem.
You definitely want to start cleaning up by throwing away connections
in the FIN_WAIT_1 state. Starting with the oldest ones may have less
impact on valid connections than simply clobbering random ones,
and/or clobbering the ones with the most buffers used.
If you've got some way to tell which connections have ever
successfully transmitted some valid data packets (i.e. gone beyond
the handshake and received any ACKs) then you might initially drop
only the connections which have not ever transmitted any data (er,
received any valid ACKs for sent packets). I guess it is possible
for the attacker(s) to work around this first-level defense though
and ACK one or two data packets first, but will they? :-)
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@acm.org> <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
(6795936) /Greg A. Woods <woods@weird.com>/(Ombruten)
Kommentar i text 6802618 av stanislav shalunov <shalunov@internet2.edu>
6802618 2001-07-25 16:07 -0400 /38 rader/ stanislav shalunov <shalunov@internet2.edu>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-27 02:20 av Brevbäraren
Extern mottagare: Greg A. Woods <woods@weird.com>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18390>
Kommentar till text 6795936 av Greg A. Woods <woods@weird.com>
Ärende: Re: FIN_WAIT_1 DoS (netkill): Why the vulnerability still exists?
------------------------------------------------------------
From: stanislav shalunov <shalunov@internet2.edu>
To: woods@weird.com (Greg A. Woods)
Cc: bugtraq@securityfocus.com
Message-ID: <8766cgkc27.fsf@cain.internet2.edu>
woods@weird.com (Greg A. Woods) writes:
> [ On , July 24, 2001 at 15:05:10 (-0400), stanislav shalunov wrote: ]
> > (I'd rather throw away random connections, with preference to those
> > that eat a lot of buffer space).
>
> That seems illogical given the nature of the problem.
[Suggestions on how to make changes to the kernel to make a particular
netkill script ineffective snipped.]
It's a solution to the wrong problem. You assume very specific
scenario and then proceed to state that attackers won't even change it
to the extent of sending another packet per connection. Can you
somehow substantiate this statement? What exactly will prevent them
from adding a dozen more lines to netkill? You must have a very
optimistic threat model.
Your scenario also assumes that it'll be necessarily new FIN_WAIT_1
connections that eat the buffer space instead of addressing a general
problem: What do you do when your finite buffer space is exhausted
while TCP spec tells you you need to maintain yet more state?
At any rate, BUGTRAQ isn't the place to solve this general problem.
Tsvwg might be...
--
Stanislav Shalunov http://www.internet2.edu/~shalunov/
Letters in this message are closer than they appear.
(6802618) /stanislav shalunov <shalunov@internet2.edu>/