Re: updated Bindview NAPTHA advisory

[Bob Keyes <bkeyes () MAIL BOS BINDVIEW COM>]

On Tue, 19 Dec 2000, Alfred Perlstein wrote:

> * Bob Keyes <bkeyes () MAIL BOS BINDVIEW COM> [001219 16:36] wrote:
> >   The NAPTHA DoS vulnerabilities
> >
> >   Issue Date: 30 November 2000
> >   Updated: 18 December 2000
> >   Contact: Robert Keyes
> >
> >   Topic:
> >
> >   Network DoS vulnerabilities
> >
> >   Overview:
> >
> >   A set of network DoS vulnerabilities has been discovered, and the name
> >   NAPTHA is being used to describe them as a group. The NAPTHA
> >   vulnerabilities are weaknesses in the way that TCP/IP stacks and network
> >   applications handle the state of a TCP connection.
>
> I thought this was already exposed as a pretty stupid vulnerability.

Childish banter on #freebsd and various freebsd mailing lists does make
for 'exposure'.

> You need local net access or you must reveal your identity for this
> attack to work (send packets with a true source address).

This is a problem for you? Getting an anonymous IP address is hardly a
challenge for a motivated and halfway talented DoS kiddie.

> This is also just another rehash of an old program called "octopus",
> just that it requires less resources to run.

As I have said before, a lame script limits the systems/services
vulnerable. Octopus is fairly lame. From the comments in
the code:

 *  The program is incomplete, in that it doesn't check for
 *  socket timeouts and subsequently reuse timed out sockets.
 *  That means the program can only keep a remote host / mud
 *  locked up until it exhausts its own available new sockets,
 *  or until it has reached MAX_DESCRIPTORS remote connections
 *  as set by the #define statement.
 *
 *  If the local machine starts issuing error messages, then
 *  the program has failed to saturate the remote host and has
 *  instead reached the limits of the local machine.  Use ^C or
 *  the kill command to terminate it.  If you are knowledgable
 *  about rebuilding kernels and have access to the root account,
 *  you can build a special kernel that will allow you to reach
 *  a much larger number of open sockets.
 *
 *  Before running this, be sure to issue the c shell command:
 *              'limit descriptors nnn'
 *  where nnn is the largest descriptor limit, as revealed
 *  by the 'limit -h' command if applicable.  Some unixes may
 *  not have a descriptors category at all.
 *

What this means is that it really doesn't attack very far before it keels
over, knocking out the attacker's machine. The ideas the octopus.c author
gives extends the limits, but they still exist and are still quickly
reached.

When you have a better attack engine, such as Naptha, there's so much more
you can do. This should be obvious if you've what we've said so far, in
the original advisory and the more detailed update.


> I can't believe you guys are still trying to gain attention with
> this bogus "vulnerability".

Various security professionals who have run the code take it seriously. I
find it hard to believe that you still feel it necessary to trash us,
when you haven't even seen the code.

> References (you'll laugh):
>
> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=111311+0+archive/2000/freebsd-security/20001210.freebsd-security

I wish I could be surprised by such a level of immaturity as this is
shown. Alas, I must admit I expected it, from the comments I have seen on
#freebsd.

> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=157312+0+archive/2000/freebsd-security/20001210.freebsd-security


> Lastly the flooding on the ssh port should have been fixed since at
> least FreeBSD 4.1.1 which is several months old.

I haven't tested it against FreeBSD other than what is mentioned in
the advisory, though I may when I get the time to reinstall it.
(Personally, I run OpenBSD and Linux). If the ssh problem is fixed, what
about the other services?

Bob Keyes

(not speaking for Bindview -- I don't have time or patience to let
the lawyers go over everything I write)