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:   Thu, 20 Jun 2019 10:36:16 -0600
From:   David Ahern <dsahern@...il.com>
To:     nicolas.dichtel@...nd.com, davem@...emloft.net
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH net] ipv6: fix neighbour resolution with raw socket

On 6/20/19 9:42 AM, Nicolas Dichtel wrote:
> Le 20/06/2019 à 17:12, David Ahern a écrit :
>> On 6/20/19 6:34 AM, Nicolas Dichtel wrote:
>>> The scenario is the following: the user uses a raw socket to send an ipv6
>>> packet, destinated to a not-connected network, and specify a connected nh.
>>> Here is the corresponding python script to reproduce this scenario:
>>>
>>>  import socket
>>>  IPPROTO_RAW = 255
>>>  send_s = socket.socket(socket.AF_INET6, socket.SOCK_RAW, IPPROTO_RAW)
>>>  # scapy
>>>  # p = IPv6(src='fd00:100::1', dst='fd00:200::fa')/ICMPv6EchoRequest()
>>>  # str(p)
>>>  req = b'`\x00\x00\x00\x00\x08:@\xfd\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\xfd\x00\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xfa\x80\x00\x81\xc0\x00\x00\x00\x00'
>>>  send_s.sendto(req, ('fd00:175::2', 0, 0, 0))
>>>
>>> fd00:175::/64 is a connected route and fd00:200::fa is not a connected
>>> host.
>>>
>>> With this scenario, the kernel starts by sending a NS to resolve
>>> fd00:175::2. When it receives the NA, it flushes its queue and try to send
>>> the initial packet. But instead of sending it, it sends another NS to
>>> resolve fd00:200::fa, which obvioulsy fails, thus the packet is dropped. If
>>> the user sends again the packet, it now uses the right nh (fd00:175::2).
>>>
>>
>> what's the local address and route setup? You reference fd00:100::1 and
>> fd00:200::fa with connected route fd00:175::/64.
>>
> 
> The test in done on the dut:
> 
>     +-----+             +------+             +------+             +-----+
>     | tnl |             | dut  |.1         .2|router|             | tnr |
>     |     |             |     2+-------------+2     |             |     |
>     |     |.1         .2|      |fd00:125::/64|      |.2         .1|     |
>     |    1+-------------+1     |             |     1+-------------+1    |
>     |     |fd00:100::/64|      |             |      |fd00:200::/64|     |
>     |     |             |      |.1         .2|      |             |     |
>     |     |             |     3+-------------+3     |             |     |
>     |     |             |      |fd00:175::/64|      |             |     |
>     +-----+             +------+             +------+             +-----+
> 
> On dut:
> ip address add fd00:100::2/64 dev ntfp1
> ip address add fd00:125::1/64 dev ntfp2
> ip address add fd00:175::1/64 dev ntfp3
> ip route add fd00:200::/64 via fd00:125::2
> ip route add fd00:200::/120 nexthop via fd00:125::2 nexthop via fd00:175::2
> 
> Note that fd00:200::fa is not reachable but we expect to see the packet on the
> host 'router'.
> 

gotcha. Thanks for the diagram.

Reviewed-by: David Ahern <dsahern@...il.com>

You don't have a fixes tag, but this should go to stable releases.

Also, this does not fix the forwarding case. For the forwarding case I
still see it trying to resolve fd00:200::fa from dut.

Namespace version of the above setup:

create_ns() {
        local ns=$1
        ip netns add ${ns}
        ip -netns ${ns} link set lo up
        ip netns exec ${ns} sysctl -qw net.ipv4.ip_forward=1
        ip netns exec ${ns} sysctl -qw net.ipv6.conf.all.keep_addr_on_down=1
        ip netns exec ${ns} sysctl -qw net.ipv6.conf.all.forwarding=1
        ip netns exec ${ns} sysctl -qw net.ipv6.conf.default.forwarding=1
}

create_ns tnl
create_ns dut
create_ns router
create_ns tnr

ip -netns tnl li add eth1 type veth peer name eth1d
ip -netns tnl li set eth1d netns dut name eth1
ip -netns tnl li set eth1 up
ip -netns tnl addr add fd00:100::1/64 dev eth1
ip -netns tnl -6 ro add default via fd00:100::2

ip -netns dut li set eth1 up
ip -netns dut addr add fd00:100::2/64 dev eth1

ip -netns dut li add eth2 type veth peer name eth2r
ip -netns dut li set eth2r netns router name eth2
ip -netns dut li set eth2 up
ip -netns dut addr add dev eth2 fd00:125::1/64
ip -netns router  li set eth2 up
ip -netns router addr add dev eth2 fd00:125::2/64

ip -netns dut li add eth3 type veth peer name eth3r
ip -netns dut li set eth3r netns router name eth3
ip -netns dut li set eth3 up
ip -netns dut addr add dev eth3 fd00:175::1/64
ip -netns router li set eth3 up
ip -netns router addr add dev eth3 fd00:175::2/64

ip -netns router li add eth1 type veth peer name eth1t
ip -netns router li set eth1t netns tnr name eth1
ip -netns router li set eth1 up
ip -netns router addr add dev eth1 fd00:200::2/64
ip -netns tnr li set eth1 up
ip -netns tnr addr add dev eth1 fd00:200::1/64

ip -netns dut route add fd00:200::/64 via fd00:125::2
ip -netns dut route add fd00:200::/120 nexthop via fd00:125::2 nexthop
via fd00:175::2

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ