From owner-freebsd-security Sat Jan 22 7:31:15 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 4F64814D31 for ; Sat, 22 Jan 2000 07:31:12 -0800 (PST) (envelope-from brett@lariat.org) Received: from workhorse (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id IAA04701; Sat, 22 Jan 2000 08:31:05 -0700 (MST) Message-Id: <4.2.2.20000122082128.01999ef0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sat, 22 Jan 2000 08:31:02 -0700 To: gdonl@tsc.tdk.com (Don Lewis), Keith Stevenson , freebsd-security@FreeBSD.ORG From: Brett Glass Subject: Re: Some observations on stream.c and streamnt.c In-Reply-To: <200001220955.BAA16447@salsa.gv.tsc.tdk.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 02:55 AM 1/22/2000 , Don Lewis wrote: >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. Yep. Right now, ICMP_BANDLIM is actually limiting RSTs as well as ICMP packets. I have not seen Matt's patch yet, but would like to see the two separated. >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. I've always thought that log_in_vain should either have or trigger a mechanism like the "repeat detector" in syslogd. As a sysadmin, I'd like it to have its own output limiting mechanism so that it can give me an intelligent summary of an attack rather than "Last message repeated 1000 times." >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. That's part of the fallout of letting an ACK match a listening socket. In your patch (and thank you, by the way; I was going to generate one a lot like it but would have had to CVSup a machine to -CURRENT first!), you've fixed this problem. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message