mailing list archives
Re: IGMP denial of service vulnerability
From: Marty Schoch <mschoch () multicasttech com>
Date: Fri, 14 Jun 2002 20:41:22 -0400
I agree with everything you've said.
But my point really was geared to, what does the spec say, and how do router
implementations handle things.
To quote RFC 2236
- "send report" for the group on the interface. The type of report
is determined by the state of the interface. The Report Message is
sent to the group being reported.
I think a router COULD reject an IGMP membership report for group G1 that
was actually delivered on group G2. I don't know that any do, but that
would seem to still be a compliant implementation.
If a router were to implement this policy, then the host implementations
must implement an equally strict policy, or else a DOS scenario can arise.
I recommended that the host implementation be modified to implement this
more strict check because the only negative side effect would be a few extra
membership reports and leave messages.
Otherwise, perhaps it should be documented that it really doesn't matter to
what group membership reports are destined to. That would seem to correctly
characterize current host/router implementations.
<mschoch () multicasttech com>
On 6/14/02 7:49 PM, "Nick Roffey" <nick () 4thline net> wrote:
Might be that I'm missing something here, but....
In the scenario mentioned, since the IGMP report is still addressed
to a group, any attached routers will receive it, which means they'll
continue to know there's at least one group member on the subnet and
carry on forwarding multicast traffic.
IGMP doesn't have any effect on what a host recieves or doesn't -
as long as there's at least one member of a multicast group on
a particular segment sending IGMP reports, an attached router will
continue to forward multicast traffic, which all hosts will receive.
CGMP, which limits multicast forwarding on switches to the ports that
have multicast group members on them, also from my documentation does
not seem to be affected. There appears to be no facility for a single
host to 'leave' via CGMP or to time out - as I understand it, only an
attached router can 'leave' CGMP - done when all IGMP group members have
left or timed out, which deletes the switch state for all members of the
group. My documentation might be out of date, but it appears that once
a group member is known to CGMP, that switch port will continue to
receive multicast traffic until all group members have gone from the
The result - the only situation where a DOS could be possible is when
the multicast sender and receiver are on different subnets AND the
multicast receiver is the only group member on that subnet.
Having said all that, unlikely though it is that this will cause any
major problems, accepting IGMP packets that are not addressed to a
group is pretty poor!
From: Arun D. Qamra [mailto:arun () cs ucsb edu]
Sent: 14 June 2002 23:21
To: Marty Schoch
Cc: bugtraq () securityfocus com
Subject: Re: IGMP denial of service vulnerability
Thats an interesting scenario. We did test the same, and DOS doesnt take
place, atleast in our test setup.
In our setup, the router (a Cisco 2514 running IOS ver12.0 in our case)
does process such a report in the scenario you suggested.
However we agree that the code should be tightened, in all systems.
On 14 Jun 2002, Marty Schoch wrote:
All IGMP packets that are not multicast ethernet addresses should be
Depending on the implementation of router R in linked document, couldn't
there still be a problem in the following scenario.
Host H1 is a member of two groups 220.127.116.11 and 18.104.22.168
Host H2 sends a membership report for group 22.214.171.124 to group
Host H1 will obviously see this report as well.
Looking briefly at the code it appears host H1 may still consider this
an acceptable report from another host. If, and I haven't tested any
router configurations, router R does not consider this a valid report
for the group 126.96.36.199 then the same DOS effect may occur.
The RFC says that membership reports should be sent to the group for
which the report applies. Why not tighten the code down all the way, to
check not just that the report is multicast, but that all the addresses
<mschoch () multicasttech com>