Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 9 Jan 2001 23:59:02 -0800
From:      Don Lewis <Don.Lewis@tsc.tdk.com>
To:        Wes Peters <wes@softweyr.com>, Don Lewis <Don.Lewis@tsc.tdk.com>
Cc:        Mike Silbersack <silby@silby.com>, Umesh Krishnaswamy <umesh@juniper.net>, freebsd-security@FreeBSD.ORG, freebsd-net@FreeBSD.ORG
Subject:   Re: Spoofing multicast addresses
Message-ID:  <200101100759.XAA20147@salsa.gv.tsc.tdk.com>
In-Reply-To: <3A5C09BE.88B4A117@softweyr.com>
References:  <Pine.BSF.4.31.0101082237330.11619-100000@achilles.silby.com> <3A5BC1D5.E5F57AE0@softweyr.com> <200101100257.SAA19637@salsa.gv.tsc.tdk.com> <3A5C09BE.88B4A117@softweyr.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 10, 12:05am, Wes Peters wrote:
} Subject: Re: Spoofing multicast addresses

} The real problem with the "stream" attack was not the volume of incoming
} SYN packets, but the reflector nature of the attack when using forged
} multicast source addresses.  The code did not correctly "ignore" these
} packets, and replied with RST.  Since no current group membership was
} available for the multicast source address, the system forwarded the RST
} packet to all attached interfaces.  Augh!

I'm actually not sure what the killer problem was.  I'm pretty sure that
systems with only one interface were vulnerable, so spewing mulitcast
RST packets out this interface shouldn't be much worse than spewing
unicast RST packets, unless I'm missing something particularly expensive
in the multicast code, which I admit that I'm not at all familiar with.
If I had to speculate, I'd guess that it might have something to do
with the multicast packets reentering the stack through the loopback
interface or maybe incoming responses to the multicast spew from other
hosts on the local network.

Since we added the packet sanity checks and the RST response rate
limiting at the same time, we really don't know which if these
helped the most.  I suppose this could be an interesting experiment
for someone with some spare time on their hands.


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?200101100759.XAA20147>