A vulnerability in Neutron anti-spoof protection. By forging DHCP discovery messages or non-IP traffic, such as ARP or ICMPv6, an instance may spoof IP or MAC source addresses on attached networks resulting in denial of services and/or traffic interception. Moreover when L2population isn't used, other tenants attached to a shared network are also vulnerable. Neutron setups using the IPTables firewall driver are affected.

Upstream bug:

https://bugs.launchpad.net/bugs/1558658

References:

http://seclists.org/oss-sec/2016/q2/519

A vulnerability in Neutron anti-spoof protection. By forging DHCP discovery messages or non-IP traffic, such as ARP or ICMPv6, an instance may spoof IP or MAC source addresses on attached networks resulting in denial of services and/or traffic interception. Moreover when L2population isn't used, other tenants attached to a shared network are also vulnerable. Neutron setups using the IPTables firewall driver are affected.

Upstream bug:

https://bugs.launchpad.net/bugs/1502933

References:

http://seclists.org/oss-sec/2016/q2/519

An uncontrolled resource consumption flaw was found in openstack-neutron. This flaw allows a remote authenticated user to query a list of security groups for an invalid project. This issue creates resources that are unconstrained by the user's quota. If a malicious user were to submit a significant number of requests, this could lead to a denial of service.

A flaw was found in openstack-neutron's default Open vSwitch firewall rules. By sending carefully crafted packets, anyone in control of a server instance connected to the virtual switch can impersonate the IPv6 addresses of other systems on the network, resulting in denial of service or in some cases possibly interception of traffic intended for other destinations. Only deployments using the Open vSwitch driver are affected. Source: OpenStack project. Versions before openstack-neutron 15.3.3, openstack-neutron 16.3.1 and openstack-neutron 17.1.1 are affected.

Live-migrated instances are briefly able to inspect traffic for other instances on the same hypervisor. This brief window could be extended indefinitely if the instance's port is set administratively down prior to live-migration and kept down after the migration is complete. This is possible due to the Open vSwitch integration bridge being connected to the instance during migration. When connected to the integration bridge, all traffic for instances using the same Open vSwitch instance would potentially be visible to the migrated guest, as the required Open vSwitch VLAN filters are only applied post-migration. Versions of openstack-neutron before 13.0.0.0b2, 12.0.3, 11.0.5 are vulnerable.

It was found that a non privileged tenant can add a router interface to a shared / external network's subnet with an IP address outside the subnet's allocation pool. This can result in a Denial of Service.

Upstream issue:

https://bugs.launchpad.net/neutron/+bug/1757482

Upstream patch:

https://git.openstack.org/cgit/openstack/neutron/commit/?id=54aa6e81cb17b33ce4d5d469cc11dec2869c762d

The L3 agent in OpenStack Neutron 2014.2.x before 2014.2.2, when using radvd 2.0+, allows remote authenticated users to cause a denial of service (blocked router update processing) by creating eight routers and assigning an ipv6 non-provider subnet to each.

OpenStack Neutron before 2014.1.4 and 2014.2.x before 2014.2.1 allows remote authenticated users to cause a denial of service (crash) via a crafted dnsnameservers value in the DNS configuration.

OpenStack Neutron before 2014.2.4 and 2014.1 before 2014.1.2 allows remote authenticated users to set admin network attributes to default values via unspecified vectors.

The notifier middleware in OpenStack PyCADF 0.5.0 and earlier, Telemetry (Ceilometer) 2013.2 before 2013.2.4 and 2014.x before 2014.1.2, Neutron 2014.x before 2014.1.2 and Juno before Juno-2, and Oslo allows remote authenticated users to obtain XAUTHTOKEN values by reading the message queue (v2/meters/http.request).

The default configuration in a sudoers file in the Red Hat openstack-neutron package before 2014.1.2-4, as used in Red Hat Enterprise Linux Open Stack Platform 5.0 for Red Hat Enterprise Linux 6, allows remote attackers to gain privileges via a crafted configuration file. NOTE: this vulnerability exists because of a CVE-2013-6433 regression.

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 (crash or long firewall rule updates) by creating a large number of allowed address pairs.

OpenStack Neutron before 2014.2.4 (juno) and 2015.1.x before 2015.1.1 (kilo), when using the IPTables firewall driver, allows remote authenticated users to cause a denial of service (L2 agent crash) by adding an address pair that is rejected by the ipset tool.

A vulnerability in Neutron anti-spoof protection. By forging DHCP discovery messages or non-IP traffic, such as ARP or ICMPv6, an instance may spoof IP or MAC source addresses on attached networks resulting in denial of services and/or traffic interception. Moreover when L2population isn't used, other tenants attached to a shared network are also vulnerable. Neutron setups using the IPTables firewall driver are affected.

Upstream bug:

https://bugs.launchpad.net/bugs/1558658

References:

http://seclists.org/oss-sec/2016/q2/519

An uncontrolled resource consumption flaw was found in openstack-neutron. This flaw allows a remote authenticated user to query a list of security groups for an invalid project. This issue creates resources that are unconstrained by the user's quota. If a malicious user were to submit a significant number of requests, this could lead to a denial of service.

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.

Yair Fried of Red Hat reports:

A regression from Grizzly and Havana exists in the PackStack rules deployed to Neutron. Specifically when default security groups are enabled they are not enforced, allowing connectivity to systems that should be blocked by the security groups.

External references: https://review.openstack.org/#/c/62702/

A vulnerability in Neutron anti-spoof protection. By forging DHCP discovery messages or non-IP traffic, such as ARP or ICMPv6, an instance may spoof IP or MAC source addresses on attached networks resulting in denial of services and/or traffic interception. Moreover when L2population isn't used, other tenants attached to a shared network are also vulnerable. Neutron setups using the IPTables firewall driver are affected.

Upstream bug:

https://bugs.launchpad.net/bugs/1558658

References:

http://seclists.org/oss-sec/2016/q2/519

A vulnerability in Neutron anti-spoof protection. By forging DHCP discovery messages or non-IP traffic, such as ARP or ICMPv6, an instance may spoof IP or MAC source addresses on attached networks resulting in denial of services and/or traffic interception. Moreover when L2population isn't used, other tenants attached to a shared network are also vulnerable. Neutron setups using the IPTables firewall driver are affected.

Upstream bug:

https://bugs.launchpad.net/bugs/1502933

References:

http://seclists.org/oss-sec/2016/q2/519

A vulnerability in Neutron anti-spoof protection. By forging DHCP discovery messages or non-IP traffic, such as ARP or ICMPv6, an instance may spoof IP or MAC source addresses on attached networks resulting in denial of services and/or traffic interception. Moreover when L2population isn't used, other tenants attached to a shared network are also vulnerable. Neutron setups using the IPTables firewall driver are affected.

Upstream bug:

https://bugs.launchpad.net/bugs/1558658

References:

http://seclists.org/oss-sec/2016/q2/519