Date: Fri, 21 Jan 2000 16:25:54 -0700 From: Wes Peters <wes@softweyr.com> To: Brett Glass <brett@lariat.org> Cc: Jared Mauch <jared@puck.nether.net>, TrouBle <trouble@netquick.net>, security@freebsd.org Subject: Re: stream.c worst-case kernel paths Message-ID: <3888EB02.7FFB4DA5@softweyr.com> References: <4.2.2.20000121143004.01908960@localhost> <4.2.2.20000121140941.01a68b30@localhost> <200001211415.BAA12772@cairo.anu.edu.au> <20000121.16082400@bastille.netquick.net> <3888C7D2.D82BE362@softweyr.com> <4.2.2.20000121140941.01a68b30@localhost> <20000121162059.Y30675@puck.nether.net> <4.2.2.20000121143004.01908960@localhost> <4.2.2.20000121145537.019bf610@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
Brett Glass wrote:
>
> 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!). Maybe this is one of the reasons why TCP_RESTRICT_RST
> seems to help defeat this exploit.
>
> [Side note: It occurs to me that George may not have tried the
> -random option in his tests, and therefore might not have
> seen this.]
That agrees with what I've seen here. I think TCP should quietly drop
any TCP packets whose source or destination is not a unicast address;
they are obviously badly formatted packets that can be nothing but evil.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
wes@softweyr.com http://softweyr.com/
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?3888EB02.7FFB4DA5>