NDP proxy allows address takeover when address scope is not used

[Dr. Jens Harbott]

When the new NDP proxy feature is configured without an address scope being used on the external network, there is no protection against addresses being used multiple times. This can be exploited by a malicious tenant via creating a subnet with a prefix that covers an address that is already in use and take over (part of) the traffic flowing towards that address. The success of the attack depends on winning the race of who answers the NDP query first, but still a 50% chance of capturing traffic seems dangerous. The attack works not only against other addresses served by NDP proxy, but also against other hosts that may exist, potentially even the gateway for the external network.

[Jeremy Stanley (fungi)]

Since this report concerns a possible security risk, an incomplete
security advisory task has been added while the core security
reviewers for the affected project or projects confirm the bug and
discuss the scope of any vulnerability along with potential
solutions.

[Jeremy Stanley (fungi)]

How "new" is "the new NDP proxy feature"? What release was it first included in (if any)?

[Dr. Jens Harbott (j-harbott)]

It is scheduled to be released with Zed, I discussed with Lajos earlier and we decided to still mark this as private for now since we cannot be sure a fix can be made until the release.

[Jeremy Stanley (fungi)]

Thanks, in that case it's class Y in our taxonomy[*] so I've marked our advisory task won't fix for now. If Zed ends up releasing with this and then the fix is backported to stable/zed, we can revisit the need for an advisory at that time.

[*] https://security.openstack.org/vmt-process.html#report-taxonomy

[Dr. Jens Harbott (j-harbott)]

Patch published in https://review.opendev.org/c/openstack/neutron/+/855850

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/855997

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/855997
Committed: https://opendev.org/openstack/neutron-tempest-plugin/commit/14d9215c9ab22e84788ce83cbc563535f2fdf1c7
Submitter: "Zuul (22348)"
Branch: master

commit 14d9215c9ab22e84788ce83cbc563535f2fdf1c7
Author: yangjianfeng <email address hidden>
Date: Tue Sep 6 10:42:29 2022 +0800

    Create extra external network with address scope for `ndp proxy` tests

    For details, please refer to https://review.opendev.org/855850

    Closes-Bug: #1987410
    Change-Id: I9f3176a9688db8c4f4417139b712d1570c5ab7bb

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/855850
Committed: https://opendev.org/openstack/neutron/commit/d600b3d433a06446abeacfb4c5de6a88774e75de
Submitter: "Zuul (22348)"
Branch: master

commit d600b3d433a06446abeacfb4c5de6a88774e75de
Author: yangjianfeng <email address hidden>
Date: Mon Sep 5 11:41:55 2022 +0800

    Forbid enable ndp proxy when external netwrok has no IPv6 address scope

    In neutron, user can create multiple ports with same IPv6 address if
    the network has no IPv6 address scope. This maybe result in some
    security issues.

    This can be exploited by a malicious tenant via creating a subnet with
    a prefix that covers an address that is already in use and take over
    (part of) the traffic flowing towards that address. The success of the
    attack depends on winning the race of who answers the NDP query first,
    but still a 50% chance of capturing traffic seems dangerous. The attack
    works not only against other addresses served by NDP proxy, but also
    against other hosts that may exist, potentially even the gateway for
    the external network.

    So, we should use `IPv6 address scope` to ensure the IPv6 address is
    unique when we want to use `ndp proxy` feature.

    Depends-on: https://review.opendev.org/#/c/855997
    Closes-Bug: #1987410
    Change-Id: I0fa431a91a7679e409386a357a01c31ec5ad0cfd

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 21.0.0.0rc1 release candidate.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron-tempest-plugin 2.0.0 release.