Adding OSSN-0027 - Neutron ARP cache poisoning vulnerability.

Closes-bug: #1274034

Change-Id: I57f41b1cd6e0ec06db2a0bf3f5496f28cffc64ed

security-notes/OSSN-0027

@@ -0,0 +1,73 @@
+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 ###
+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