Date: Fri, 21 Jan 2000 16:35:44 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Brett Glass <brett@lariat.org> Cc: Warner Losh <imp@village.org>, Darren Reed <avalon@coombs.anu.edu.au>, security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <200001220035.QAA65392@apollo.backplane.com> References: <200001210417.PAA24853@cairo.anu.edu.au> <200001210642.XAA09108@harmony.village.org> <4.2.2.20000121163937.01a51dc0@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
:> RST cases but the above two cases usually handle the vast majority of
:> these sorts of attacks so if this exploit code is stopped cold by ICMP_BANDLIM,
:> we're done. If it isn't then we spend a few seconds extending the cases
:> covered by ICMP_BANDLIM and we are done.
:
:I'd certainly like to see this extended to RST. We can optimize socket searching
:and prevent TCP from sending RSTs (or anything!) to multicast addresses at the
:same time. (We probably also want to block RECEIVED TCP packets from multicast
:addresses, as Wes suggests.)
:
:--Brett
I wouldn't worry about multicast addresses for several reasons. First, very
few machines actually run a multicast router. No router, no problem. Second,
multicast tunnels tend to be bandwidth limited anyway. Third, from the point
of view of victimizing someone multicast isn't going to get you very far
because we already check for a multicast destination. We don't really need
to check for a multicast source because it's really no different from a
victimizing point of view as a non-multicast source address.
-Matt
Matthew Dillon
<dillon@backplane.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?200001220035.QAA65392>