Date: Wed, 26 Jul 2000 00:29:05 -0600 From: Wes Peters <wes@softweyr.com> To: Tim Yardley <yardley@uiuc.edu> Cc: Don Lewis <Don.Lewis@tsc.tdk.com>, Maksimov Maksim <maksim@tts.tomsk.su>, freebsd-security@FreeBSD.ORG Subject: Re: How defend from stream2.c attack? Message-ID: <397E8531.AE1DF9F@softweyr.com> References: <000401bfdb64$3eae8320$0c3214d4@dragonland.tts.tomsk.su> <000401bfdb64$3eae8320$0c3214d4@dragonland.tts.tomsk.su> <4.3.2.7.2.20000725181153.0218d700@students.uiuc.edu> <4.3.2.7.2.20000725223522.00b5dcc0@students.uiuc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Tim Yardley wrote:
>
> >With FreeBSD prior to 3.4/4.0 it didn't matter if you were attempting to
> >use multicast or not, a stream attack using random multicast source
> >addresses would turn your FreeBSD box into an attack reflector on every
> >attached interface. Urk!
>
> Correct. The blocking of multicast statement was meant for people that DO
> NOT use multicast. If you use multicast, then you cannot block it at the
> router. In otherwords, block * with multicast addresses. You could always
> just block tcp with multicast addresses, and that will not affect any real
> multicast traffic.
>
> >That no longer happens; the code now realizes that a TCP packet from a
> >multicast address is malformed and dumps it on the floor.
>
> Any sane stack would drop the multicast packets on the floor immediately if
> they are TCP packets. That is basically what the patch did. Since the
> notion of TCP multicast is not even possible, that is the correct thing to do.
But then again, that problem existing in the 4.2BSD stack and lived on
until a few months ago.
--
"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?397E8531.AE1DF9F>