In OpenStack Neutron before 28.0.1, a project manager can create or update a port on a shared network owned by another project and set deviceowner to a value that has "network:" at the beginning ("network:dhcp" for example). The default port RBAC policies incorrectly included PROJECTMANAGER 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 (OSSA-2015-018).

It was reported that a vulnerability was found in Neutron. By changing the device owner of an instance's port right after it is created, an authenticated user may prevent application of firewall rules and so avoid IP anti-spoofing controls. All Neutron setups using the ML2 plugin or a plugin that relies on the security groups AMQP API are affected. All Neutron setups using the ML2 plugin or a plugin that relies on the security groups AMQP API are affected.

Vulnerability affects versions through 2014.2.3 and 2015.1 versions through 2015.1.1

Acknowledgements:

Red Hat would like to thank the OpenStack project for reporting this issue. Upstream acknowledges Kevin Benton from Mirantis as the original reporter.

The L3-agent in OpenStack Neutron before 2013.2.4, 2014.x before 2014.1.2, and Juno before Juno-2 allows remote authenticated users to cause a denial of service (IPv4 address attachment outage) by attaching an IPv6 private subnet to a L3 router.

The l3-agent in OpenStack Neutron 2012.2 before 2013.2.3 does not check the tenant id when creating ports, which allows remote authenticated users to plug ports into the routers of arbitrary tenants via the device id in a port-create command.