netdev - 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAJzqFtbXdrFYmRj7r1CF+1jH0KcH8EVG-yVdF3yMcAdzHWL5_A@mail.gmail.com>
Date:   Fri, 8 Dec 2017 21:25:58 -0800
From:   Kevin Cernekee <cernekee@...omium.org>
To:     netdev@...r.kernel.org
Subject: Incorrect source IP address on IGMP membership report

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?

I was able to suppress these reports with an iptables OUTPUT rule, but
maybe there is a cleaner way.

[0] https://bugs.chromium.org/p/chromium/issues/detail?id=786514