Date: Fri, 21 Jan 2000 15:50:32 -0800 From: gdonl@tsc.tdk.com (Don Lewis) To: Brett Glass <brett@lariat.org>, Jared Mauch <jared@puck.nether.net> Cc: Wes Peters <wes@softweyr.com>, TrouBle <trouble@netquick.net>, security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <200001212350.PAA14888@salsa.gv.tsc.tdk.com> In-Reply-To: Brett Glass <brett@lariat.org> "Re: stream.c worst-case kernel paths" (Jan 21, 3:08pm)
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 21, 3:08pm, Brett Glass wrote: } Subject: Re: stream.c worst-case kernel paths } I can see that in icmp.c, there is a test that prevents us from } sending an ICMP packet to a multicast address. And in tcp_input.c, } the code near the label "dropwithreset" prevents a RST from being } sent in response to a packet whose DESTINATION was a multicast } address. But I don't see anything that stops it from going } out when the SOURCE was a multicast address. So TCP attempts } to send a RST to that address (something that should be } fixed!). Barf! If this is the problem, then IPFW should be able to block the attack. I'm tempted to move the existing multicast tests up to the top of tcp_input() and check the source address as well. I just hate to add extra code to the main code path, though. 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?200001212350.PAA14888>