netdev - Re: Incorrect source IP address on IGMP membership report

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20171209160116.GA2299@lunn.ch>
Date:   Sat, 9 Dec 2017 17:01:16 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Kevin Cernekee <cernekee@...omium.org>
Cc:     netdev@...r.kernel.org
Subject: Re: Incorrect source IP address on IGMP membership report

On Fri, Dec 08, 2017 at 09:25:58PM -0800, Kevin Cernekee wrote:
> Closing a multicast socket after the final IPv4 address is deleted
> from an interface will generate a membership report that uses the
> source IP from a different interface.  The following test script, run
> from an isolated netns, reproduces the issue:
> 
>     #!/bin/bash
> 
>     ip link add dummy0 type dummy
>     ip link add dummy1 type dummy
>     ip link set dummy0 up
>     ip link set dummy1 up
>     ip addr add 10.1.1.1/24 dev dummy0
>     ip addr add 192.168.99.99/24 dev dummy1
> 
>     tcpdump -U -i dummy0 -w dummy0.pcap &
>     socat EXEC:"sleep 2"
> UDP4-DATAGRAM:239.101.1.68:8889,ip-add-membership=239.0.1.68:10.1.1.1
> &
> 
>     sleep 1
>     ip addr del 10.1.1.1/24 dev dummy0
>     sleep 5
>     kill %tcpdump
> 
> After running this script, dummy0.pcap contains one Membership Report
> / Join Group packet with source IP 10.1.1.1, and two Membership Report
> / Leave Group packets with source IP 192.168.99.99.
> 
> Sending out multicasts on the LAN using an unexpected source IP
> address seems to be causing issues in some enterprise environments[0],
> where the network infrastructure is set up to flag suspicious packets.
> 
> I believe the source address is provided by ip_route_output_ports()
> called from igmpv3_newpack() in the kernel.
> 
> Is this behavior intentional?  If not, is it something that we should fix?

Hi Kevin

The choice of IP address for IGMP in Linux is 'interesting'.  Try with
multiple IP addresses on the interfaces, addresses with different
scopes, etc.  I've seen it reply to the querier using an address from
a different subnet to the incoming request, etc.

Part of it is an implementation problem. When the application did a
join, it passed an IP address to identify the interface to perform the
join on. That IP address would be an idle choice for IGMP for that
group. However, the information gets discard once the interface has
been determined.

With a single IP address on a single interface, Linux IGMP probably
works. Outside of that, expect oddness.

In your particular case, it is a global scope address. You are allowed
to use it on any interface. So it should not really trigger suspicious
activity. However, the RFC about multicast suggests IGMP with an
unexpected source address should be dropped. However, it is only a
should, not a must, if i remember correctly.

       Andrew