OSSN/OSSN-0027

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