netdev - Re: [PATCH net-next] vrf: local route leaking

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: <20190531103832.GA17076@gwilkie-Precision-7520>
Date:   Fri, 31 May 2019 11:38:32 +0100
From:   George Wilkie <gwilkie@...tta.att-mail.com>
To:     David Ahern <dsahern@...il.com>
Cc:     Shrijeet Mukherjee <shrijeet@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        netdev@...r.kernel.org
Subject: Re: [PATCH net-next] vrf: local route leaking

On Thu, May 30, 2019 at 03:50:09PM -0600, David Ahern wrote:
> On 5/30/19 2:52 PM, George Wilkie wrote:
> > This doesn't work for me (again, not using namespaces).
> > For traffic coming in on vrf-b to a destination on 10.200.2.0,
> > I see ARPs going out for the destination on xvrf2/in on xvrf1,
> > but nothing replies to it.
> 
> Is rp_filter set?
> 

No, but arp_filter and arp_ignore was.
After setting net.ipv4.conf.all.arp_ignore=0 and
net.ipv4.conf.xvrf1.arp_filter=0 I can get ARP replies to the local address
but unsurprisingly not to the peer address.
So would only be able to leak the local /32 in this way,
and leak the /24 via the interface:
   sysctl net.ipv4.conf.all.arp_ignore=0
   ip li add xvrf1 type veth peer name xvrf2
   ip li set xvrf1 up
   ip li set xvrf2 master vrfA up
   sysctl net.ipv4.conf.xvrf1.arp_filter=0
   ip ro add vrf vrfA 10.10.3.0/24 dev enp1s3
   ip ro add vrf vrfA 10.10.3.2/32 dev xvrf2
   ip ro add 10.10.2.0/24 dev vrfA

It doesn't help for ipv6 though. No response to the neighbor solicitation.

What are your thoughts on creating a "vrfdefault" for "local" table?
   ip link add vrfdefault type vrf table local
   ip link set dev vrfdefault up
   ip ro add vrf vrfA 10.10.3.0/24 dev vrfdefault
   ip ro add 10.10.2.0/24 dev vrfA
   ip -6 ro add vrf vrfA 10:10:3::/64 dev vrfdefault
   ip -6 ro add 10:10:2::/64 dev vrfA

I'm able to reach local and peer addresses for both v4 and v6 with this
approach.