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 17:42:48 +0200
From:   Nicolas Dichtel <nicolas.dichtel@...nd.com>
To:     David Ahern <dsahern@...il.com>, davem@...emloft.net
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH net] ipv6: fix neighbour resolution with raw socket

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'.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ