Date: Fri, 21 Jan 2000 15:08:37 -0700 From: Brett Glass <brett@lariat.org> To: Jared Mauch <jared@puck.nether.net> Cc: Jared Mauch <jared@puck.nether.net>, Wes Peters <wes@softweyr.com>, TrouBle <trouble@netquick.net>, security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <4.2.2.20000121145537.019bf610@localhost> In-Reply-To: <20000121164856.A4055@puck.nether.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.]
--Brett
At 02:48 PM 1/21/2000 , Jared Mauch wrote:
> Packet comes in, and we look at type first I believe.
>
> RCV IP PKT -> Determine type enum { tcp udp raw ospf icmp ... }
>
> pass off to appropriate stack. udp stack deals with multicast,
>but if you receive traffic to a multicast address, that you haven't sent
>an igmp join to, you should drop the packet without looking at it further
>(Unless you are a multicast router).
>
> The TCP stack should discard 224.0.0.0/4 when it comes in if
>the src or dst are within that range.
>
> - Jared
>
>On Fri, Jan 21, 2000 at 02:35:16PM -0700, Brett Glass wrote:
> > That's what I thought. This is really pathological. Why do we allow
> > ourselves to send a RST to a multicast address, or accept an ACK from
> > one? Could lower layers of the stack flag the ACK as coming from
> > a multicast address so that we can nuke it before (or as) it hits
> > the TCP layer? I can imagine a whole potential family of exploits
> > involving multicast addresses and TCP.
> >
> > --Brett
> >
> > At 02:20 PM 1/21/2000 , Jared Mauch wrote:
> >
> > > In the multicast world you only send UDP (or other types), you
> > >do not send tcp packets out, because you can't do a three-way
> > >handshake.
> > >
> > > - jared
> > >
> > >On Fri, Jan 21, 2000 at 02:10:23PM -0700, Brett Glass wrote:
> > > > At 01:55 PM 1/21/2000 , Wes Peters wrote:
> > > >
> > > > >Be warned if you're using the exploit program: if you select random
> > > > >addresses, it may (will) pick multicast IP addresses, which may have
> > > > >unintended side affects on your network. Augh!
> > > >
> > > > Geeze. Is it even LEGAL to ACK multicast packets?
> > > >
> > > > --Brett
> > > >
> > > >
> > > >
> > > > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > > > with "unsubscribe freebsd-security" in the body of the message
> > >
> > >--
> > >Jared Mauch | pgp key available via finger from jared@puck.nether.net
> > >clue++; | http://puck.nether.net/~jared/ My statements are only mine.
> > >END OF LINE |
>
>--
>Jared Mauch | pgp key available via finger from jared@puck.nether.net
>clue++; | http://puck.nether.net/~jared/ My statements are only mine.
>END OF LINE |
>
>
>To Unsubscribe: send mail to majordomo@FreeBSD.org
>with "unsubscribe freebsd-security" in the body of the message
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.20000121145537.019bf610>