1bf55f1eb0
All OSSN authors, added under the "Author:" metadata field Change-Id: I81771dd3ec8d2c133ebc6ddf9f2c5f0f958d603a Closes-Bug: #1599064
75 lines
3.1 KiB
Plaintext
75 lines
3.1 KiB
Plaintext
Neutron ARP cache poisoning vulnerability
|
|
---
|
|
|
|
### Summary ###
|
|
The Neutron firewall driver 'iptables_firewall' does not prevent ARP
|
|
cache poisoning, as this driver is currently only capable of MAC address
|
|
and IP address based anti-spoofing rules. However, ARP filtering
|
|
functionality is available in Nova Networking.
|
|
|
|
### Affected Services / Software ###
|
|
Neutron, Grizzly, Havana, Icehouse, Juno
|
|
|
|
### Discussion ###
|
|
In deployments using Nova Networking, the following anti-spoofing rules
|
|
are available through the libvirt network filter feature:
|
|
|
|
- no-mac-spoofing
|
|
- no-ip-spoofing
|
|
- no-arp-spoofing
|
|
- nova-no-nd-reflection
|
|
- allow-dhcp-server
|
|
|
|
However, in deployments using Neutron, the 'iptables_firewall' driver
|
|
handles only MAC and IP anti-spoofing rules, leaving it vulnerable to
|
|
ARP poisoning and associated attacks. This feature disparity is a
|
|
security vulnerability, especially on networks shared with other tenants
|
|
or services.
|
|
|
|
ARP poisoning can lead to denial of service attacks as well as man in
|
|
the middle attacks that can compromise tenant separation on shared
|
|
networks. A malicious host on the shared network can send crafted ARP
|
|
packets designed to manipulate the ARP table of another host on the same
|
|
network. This manipulation can be engineered such that the malicious
|
|
host will receive traffic from the target host in place of the network
|
|
gateway. The malicious host has a number of options once traffic has
|
|
been intercepted. It may interrogate it for sensitive information,
|
|
manipulate if before passing it on to the real gateway, or drop it to
|
|
create a denial of service attack.
|
|
|
|
This can be demonstrated as follows:
|
|
|
|
- Create a private network/subnet 10.0.0.0/24
|
|
- Start 2 VMs attached to that private network:
|
|
VM1 IP 10.0.0.3, VM2 IP 10.0.0.4
|
|
- Log on to VM1 and install the ettercap tool (see references)
|
|
- Launch command: 'ettercap -T -w dump -M ARP /10.0.0.4/ // output' on
|
|
VM1. This will cause traffic from VM2 to pass through VM1 before it is
|
|
forwarded on to the gateway.
|
|
- Log on to VM2 and ping any valid internet site, the ping should
|
|
succeed.
|
|
- The ICMP traffic generated by VM2's ping will be visible on VM1.
|
|
- Checking the ARP table on VM2 will show that the MAC address
|
|
associated with the gateway is the MAC address of VM1.
|
|
|
|
This technique can be used to cause a denial of service attack if VM1
|
|
drops packets from VM2 rather than forwarding them on to the gateway.
|
|
|
|
### Recommended Actions ###
|
|
Pay close attention to networks where Neutron-based VLANs are in use.
|
|
Install appropriate IDS and traffic monitoring tools with a particular
|
|
focus on ARP packet monitoring.
|
|
|
|
The Neutron development team plan to address this issue in a future
|
|
version
|
|
|
|
### Contacts / References ###
|
|
Author: Tim Kelsey, HPE
|
|
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0027
|
|
Original LaunchPad Bug : https://bugs.launchpad.net/neutron/+bug/1274034
|
|
OpenStack Security ML : openstack-security@lists.openstack.org
|
|
OpenStack Security Group : https://launchpad.net/~openstack-ossg
|
|
Ettercap: http://ettercap.github.io/ettercap
|
|
ARP Poisoning: http://en.wikipedia.org/wiki/ARP_spoofing
|
|
http://www.watchguard.com/infocenter/editorial/135324.asp
|