Date: Wed, 10 Jan 2001 00:05:34 -0700 From: Wes Peters <wes@softweyr.com> To: 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: <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>
next in thread | previous in thread | raw e-mail | index | archive | help
Don Lewis wrote:
>
> [ freebsd-net added ]
>
> On Jan 9, 6:58pm, Wes Peters wrote:
> } Subject: Re: Spoofing multicast addresses
> } Mike Silbersack wrote:
> } >
> } > The check is done when the SYN is received, hence such a situation as you
> } > describe should not be able to occur.
> } >
> } > >From tcp_input.c:
> } >
> } > /*
> } > * RFC1122 4.2.3.10, p. 104: discard bcast/mcast SYN
> } > * in_broadcast() should never return true on a received
> } > * packet with M_BCAST not set.
> } > *
> } > * Packets with a multicast source address should also
> } > * be discarded.
> } > */
> } > if (m->m_flags & (M_BCAST|M_MCAST))
> } > goto drop;
>
> There are some additional sanity checks that were omitted from this message.
>
> } The real problem is this check is 675 lines into tcp_input, but probably
> } should be at the top. I've just rescanned this and don't recall if m->m_flags
> } is set before tcp_input is called, or by one of the numerous functions called
> } in the code leading up to this check.
>
> The flags are set before tcp_input is called based on link level
> information.
>
> A good reason for putting these checks in their present location is
> that it gets them out of the main code path. Under normal circumstances,
> the vast majority of the incoming packets will be for established
> connections and it wasteful to do unnecessary checking on these packets.
But that is exactly NOT the case when being attacked with a SYN flood
or something like that. Perhaps it would be advantageous to trip a flag
if we hit the bandwidth limiting rate and do the checks much earlier only
if we're under attack?
> We need to do a PCB lookup for each incoming packet in any case, so if
You certainly don't NEED to do a PCB lookup for a TCP packet with a
{broad,multi}cast address, ever.
> we never create a PCB containing any invalid addresses, then we only
> need the extra sanity checking on packets that don't have a matching PCB.
> Optimising the most frequently used code path leaves more CPU cycles
> available for the application.
>
> Now if someone floods the server with garbage packets, we'll expend
> more CPU cycles handling them than if the sanity check was done first,
> but there are likely to be spare CPU cycles available because the
> real clients won't be getting through the flood to exercise the application
> code.
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!
What do you think of my suggestion above, to shift into "flood avoidance
mode" when rate limits are hit on either RST or drop? That has some
potential for nearly best of both worlds performance, as long as the
rate limit threshold is adjusted carefully. You'd want to tune the
setting to avoid flapping the mode flag on and off.
> } The comment about discarding bcast/mcast SYN is misleading, there is NO
> } properly formatted TCP packet *to or from* a broadcast or multicast address.
>
> See what the RFC1122 4.2.3.10 says.
It says exactly what I said, in more formal language, but is typically a
little vague as to what to do about it. The second paragraph, "...or by the
IP layer..." gives a hint as to the appropriate place to really check for
this class of errors.
--
"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?3A5C09BE.88B4A117>