From owner-freebsd-security  Sat Jan 22  1:55:58 2000
Delivered-To: freebsd-security@freebsd.org
Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21])
	by hub.freebsd.org (Postfix) with ESMTP id 0057414DE0
	for <freebsd-security@FreeBSD.ORG>; Sat, 22 Jan 2000 01:55:56 -0800 (PST)
	(envelope-from gdonl@tsc.tdk.com)
Received: from imap.gv.tsc.tdk.com (imap.gv.tsc.tdk.com [192.168.241.198])
	by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id BAA20016;
	Sat, 22 Jan 2000 01:55:50 -0800 (PST)
	(envelope-from gdonl@tsc.tdk.com)
Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194])
	by imap.gv.tsc.tdk.com (8.9.3/8.9.3) with ESMTP id BAA54067;
	Sat, 22 Jan 2000 01:55:49 -0800 (PST)
	(envelope-from Don.Lewis@tsc.tdk.com)
Received: (from gdonl@localhost)
	by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id BAA16447;
	Sat, 22 Jan 2000 01:55:49 -0800 (PST)
Message-Id: <200001220955.BAA16447@salsa.gv.tsc.tdk.com>
From: gdonl@tsc.tdk.com (Don Lewis)
Date: Sat, 22 Jan 2000 01:55:49 -0800
In-Reply-To: Brett Glass <brett@lariat.org>
       "Re: Some observations on stream.c and streamnt.c" (Jan 21,  2:44pm)
X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98)
To: Brett Glass <brett@lariat.org>,
	Keith Stevenson <k.stevenson@louisville.edu>,
	freebsd-security@FreeBSD.ORG
Subject: Re: Some observations on stream.c and streamnt.c
Sender: owner-freebsd-security@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

On Jan 21,  2:44pm, Brett Glass wrote:
} Subject: Re: Some observations on stream.c and streamnt.c
} At 02:27 PM 1/21/2000 , Keith Stevenson wrote:
} 
} >The ICMP_BANDLIM seemed to be the life saver.  I got tons of
} >"icmp-response bandwidth limit" messages in my syslog, but the load didn't
} >climb and I was still able to provide network services from the target host.
} 
} That's probably because one of the things the exploit does is to create
} an ICMP storm. Looks like it's triggered by the outgoing RST, which in
} turn is sent in response to the bogus ACK.

I think the message is misleading in this case and is being triggered
by the following code, which will cause the above message to be logged
when we try to send too many RST responses:

        if (inp == NULL) {
                if (log_in_vain) {
[ snip ]
                }
#ifdef ICMP_BANDLIM
                if (badport_bandlim(1) < 0)
                        goto drop;
#endif                  
                if (blackhole) {
                        switch (blackhole) {
                        case 1:
                                if (thflags & TH_SYN)
                                        goto drop;
                                break;
                        case 2:
                                goto drop;
                        default:
                                goto drop;
                        }
                }       
                goto dropwithreset;
        }        


If you attack a destination port that doesn't have a listening socket (or
you attack random ports, most of which won't have listening sockets, inp
will be NULL and the above code will be invoked.  ICMP_BANDLIM will keep
the code from falling through to dropwithreset the vast majority of the
time, saving your bacon.

Does anyone else think that the order of the above three tests is exactly
backwards?  This attack will really DoS the machine if you have log_in_vain
turned on.

If the attack is directed against a port with a listening socket, then
the above code is not invoked and the branch to dropwithreset happens
further down in the code at a place no protected by ICMP_BANDLIM.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message