netdev - Re: Multicast packets visible on different subnets in different namespaces

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]

Message-ID: <CAPhDKbGMm0jLrV=+0HFTx6FQrPdakzn9Bm6VCLdXPWmyQw5A8A@mail.gmail.com>
Date:	Mon, 18 May 2015 12:55:48 +0100
From:	Ilya Dmitrichenko <errordeveloper@...il.com>
To:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: Multicast packets visible on different subnets in different namespaces

Hello List,

I am wondering if anyone has looked into this yet?

Regards,
—
Ilya Dmitrichenko

On 30 March 2015 at 13:05, Ilya Dmitrichenko <errordeveloper@...il.com> wrote:
> Hello List,
>
> We have recently discovered that namespaced processes in different
> subnets can unexpectedly see each other’s multicast packets under
> certain condition described below.
>
> We setup 3 network namespace, let's call those A, B and C; where
> subnets are assigned like so:
>
> A: 10.20.1.2/24
> B: 10.20.1.4/24
> C: 10.20.2.2/24
>
> These namespaces are setup with a simple script using ip command [1].
> The value of rp_filter is 1 (in all of
> `/proc/sys/net/ipv4/conf/*/rp_filter`, except from `lo`).
>
> First, as a sanity check, A is unreachable from namespace C through
> either ping, TCP or UDP, which is what’s expected.
>
> However, when doing a multicast test with a commonly known program
> [2], it turns out that -
>
> 1. sender from C cannot reach receiver in A at first
> 2. sender from B reaches receiver in A
> 3. unexpectedly, sender from C can reach receiver in A, after B has
> reached it once
>
> This is the exact sequence of commands we used to reproduce the issue:
>
> shell1: sudo ip netns exec nsA mcreceive 224.2.2.4 5050
> shell2: echo hi1 | sudo ip netns exec nsC mcsend 224.2.2.4 5050
> shell2: echo h2 | sudo ip netns exec nsB mcsend 224.2.2.4 5050
> shell2: echo hi3 | sudo ip netns exec nsC mcsend 224.2.2.4 5050
>
> The kernel versions we have tested are:
>
> 3.18.7-100 from Fedora 20.
> 3.19.0 from CoreOS
>
> [0]: https://github.com/errordeveloper/subleak/blob/master/test.sh
> [1]: http://www.nmsl.cs.ucsb.edu/MulticastSocketsBook/c_send_receive.tar.gz
>
> Regards,
> —
> Ilya Dmitrichenko
--
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