Date: Sat, 22 Jan 2000 08:31:02 -0700 From: Brett Glass <brett@lariat.org> To: gdonl@tsc.tdk.com (Don Lewis), Keith Stevenson <k.stevenson@louisville.edu>, freebsd-security@FreeBSD.ORG Subject: Re: Some observations on stream.c and streamnt.c Message-ID: <4.2.2.20000122082128.01999ef0@localhost> In-Reply-To: <200001220955.BAA16447@salsa.gv.tsc.tdk.com> References: <Brett Glass <brett@lariat.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.2.2.20000122082128.01999ef0>