Description
===
In multiple versions of Open vSwitch, if OpenFlow rules on a switch
contain a match on a Target Address (nd_target) of Neighbor Discovery
IPv6 packets (Neighbor Solicitation or Neighbor Advertisement) without
also matching on ICMPv6 Code (icmp_code or icmpv6_code) field being
zero, the match on the Target Address can be ignored and the specified
actions may be executed for a packet with a different Target Address.
This constitutes vulnerability if such OpenFlow rules are used in order
to provide Neighbor Discovery anti-spoofing protection. For example,
the following set of rules may allow packets with any nd_target, even
though it should only allow packets with the 2001::1 Target:
priority=10 icmp6,icmpv6_type=136,nd_target=2001::1 actions=
priority=0 icmp6 actions=drop
The issue is caused by the difference between the OpenFlow specification
that only lists ICMPV6 TYPE=135 or ICMPV6 TYPE=136 as a prerequisite for
the IPV6_ND_TARGET and datapath implementations that treat ICMPV6_CODE=0
as a requirement for a packet to have the Target Address option. This
leads to creation of an overly broad datapath flow that matches packets
regardless of the Target Address value.
Triggering the issue depends on the order in which packets are seen
by the switch.
Open vSwitch versions 2.1 and newer are affected.
The Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned CVE-2023-5366 identifier to this issue.
Mitigation
==
For any affected version of Open vSwitch, adding an icmpv6_code=0 match
to an OpenFlow rule will mitigate the issue. For example:
priority=10 icmp6,icmpv6_type=136,icmpv6_code=0,nd_target=2001::1 \
actions=
priority=0 icmp6 actions=drop
'icmpv6_code' corresponds to OXM_OF_ICMPV6_CODE staring with OF1.2
or NXM_OF_ICMPV6_CODE Nicira Extension before that.
Fix
===
Patches to fix this vulnerability in Open vSwitch 2.17 and newer has been
applied to the appropriate branches:
* 3.2.x:
https://github.com/openvswitch/ovs/commit/7570744c5add3a91b468c4ffa5bc73ef1f5bb18a
* 3.1.x:
https://github.com/openvswitch/ovs/commit/d3f9eab1abbb6a11c2a166472c184f54fd740bf1
* 3.0.x:
https://github.com/openvswitch/ovs/commit/a6c0a3deb268f34faef0062e2c05ece563d50ecb
* 2.17.x:
https://github.com/openvswitch/ovs/commit/e235a421fbdb0c70176e8a3bef13bf7e2056cbc1
The original patch is located at:
https://mail.openvswitch.org/pipermail/ovs-dev/2024-February/411701.html
Note for those performing selective patch backports:
The following change is a prerequisite for the fix and must also be
applied for the fix to work correctly:
https://github.com/openvswitch/ovs/commit/489553b1c21692063931a9f50b6849b23128443c
Recommendation
==
We recommend that users of Open vSwitch apply the respective patches,
or upgrade to a known patched version of Open vSwitch. These include:
* 3.2.2
* 3.1.4
* 3.0.6
* 2.17.9
However, while patches are enough to fix the issue, checking both the
ICMPv6 Code and Type is *the correct way* to validate Neighbor Discovery
packets according to RFC 4861. With this in mind, we recommend that
users follow the mitigation strategy even with the patches applied,
i.e. add an extra match criteria on 'icmpv6_code' field.
Acknowledgments
===
The Open vSwitch team wishes to thank the reporters:
* Alex Katz
* Slawomir Kaplonski
OpenPGP_0xB9F7EC77C829BF96.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
