netdev - Re: [PATCH] IPv4 Multicast: prevent reception of mcast frames from unjoined groups

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 11 Jul 2008 14:23:04 -0400
From:	Neil Horman <nhorman@...driver.com>
To:	David Stevens <dlstevens@...ibm.com>
Cc:	davem@...emloft.net, jmorris@...ei.org, kaber@...sh.net,
	Alexey Kuznetsov <kuznet@....inr.ac.ru>,
	netdev@...r.kernel.org, pekkas@...core.fi, yoshfuji@...ux-ipv6.org
Subject: Re: [PATCH] IPv4 Multicast: prevent reception of mcast frames from
	unjoined groups

On Fri, Jul 11, 2008 at 10:53:01AM -0700, David Stevens wrote:
> > currently in ip_mc_sf_allow we assume that we need to allow the frame if 
> no
> > match is found, but that has the affect of causing frames to be received 
> for
> > groups a socket hasn't joined.  I asked david aobut this specifically.
> 
>         You asked me about this? Or the other David? :-) I don't remember
> seeing anything on this-- at least not recently.
> 
It was you (I wrote from my rh address :)), the question of note that I asked
you about:

>>>
>>> 4) Finally, what if process B bound itself to INADDR_ANY rather than to
>>>the
>>> specific multicast group.  Should it see process A's sent frames then?
>>
>>        Not if the group membership is on lo and the sends are on eth0.
>>The
>>reason it isn't seeing the packets is not the binding, but the group
>>membership. To hear packets you're sending out an interface, you must
>>join that group on that interface *and* the sender must allow loopback by
>>not clearing IP_MULTICAST_LOOP. Joining the group on a different interface
>>really is joining a different group, as far as multicasting is concerned.

>         But in the sentence above, I think you missed the point of the
> mail I sent before. Joining a group or not on a particular socket has
> nothing at all to do with delivery of multicasts to the socket.
> 
>         Multicast addresses, like unicast addresses, are for the entire
> machine, not just the socket that does the join. If anyone on the
> machine has joined the group and your binding matches the packet, you
> will receive a copy. That's intentional. If you don't join any groups
> at all, but bind to INADDR_ANY, you will receive packets for the port
> and protocol and any local unicast or multicast address (including
> groups joined by any other process on the machine).
> 
>  +-DLS

If thats the final word, then I'll believe you, but it seems to me that
receiving multicast traffic on a socket that didn't specifically join a
multicast group is asking for trouble, as every application needs to be prepared
to handle data payloads it was not expected to recieve.

Can you clarify your statement above with the one that I copied in from you
earlier?

Regards
Neil


-- 
/****************************************************
 * Neil Horman <nhorman@...driver.com>
 * Software Engineer, Red Hat
 ****************************************************/
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html