CVE-2023-3637

The IPTables firewall in OpenStack Neutron before 7.0.4 and from 8.0.0 to 8.1.0 allows remote attackers to bypass an intended MAC-spoofing protection mechanism, potentially leading to denial of service or interception of network traffic.

The IPTables firewall in OpenStack Neutron before 7.0.4 and from 8.0.0 to 8.1.0 allows remote attackers to bypass an intended DHCP-spoofing protection mechanism, potentially leading to denial of service or interception of network traffic via a crafted DHCP discovery message.

The openvswitch-agent process in OpenStack Neutron versions 2013.1 before 2013.2.4 and 2014.1 before 2014.1.1 allows remote authenticated users to bypass security group restrictions via an invalid CIDR in a security group rule, which prevents further rules from being applied.

The IPTables firewall in OpenStack Neutron before 7.0.4 and from 8.0.0 to 8.1.0 allows remote attackers to bypass an intended ICMPv6-spoofing protection mechanism, potentially leading to denial of service or interception of network traffic via a link-local source address.

In OpenStack Neutron before 28.0.2, the subnetpool onboarding API does not verify ownership of the target subnets. An authenticated user can onboard subnets from another project's shared network into their own subnetpool, mutating the victim's subnet state and altering L3 routing and address scope behavior for victim routers.

In OpenStack Neutron before version 28.0.1, a project manager can create or update a port on a shared network owned by another project and set device_owner to a value starting with "network:". Default port RBAC policies incorrectly included PROJECT_MANAGER without requiring network ownership, allowing any project manager to obtain trusted network-service port behavior on shared networks. Depending on backend and deployment, this can bypass anti-spoofing and security group protections, enabling DHCP, MAC, or IP spoofing against other tenants on the shared network. This is a regression of CVE-2015-5240.

In OpenStack Neutron before version 28.0.1, the tagging controller enforces plural policy action names on single-tag write operations while the defined policy rules use singular names. The mismatched names evaluate as allowed under the default policy, permitting a project reader to create and update tags on same-project resources.