Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 at 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUGGHfAAoJEJa+6E7Ri+EVqOgH/0Jih4BmeGXsATY4U9V/gX/W
XNvkIqN4ZaiSuaFZ+x2muAMhqMio2DeANWsbtJlywB8WiJfDrRyo/jwbn+ypJFEk
TUa5XTua+4DiPihcLaHGAwc0HJEFI9EDRJOGHsLWZVDpYP5aiWU9h/vqh7kbO84u
n0IYP5o2IZxSX7xPWf8zNftAKqkDBOOIDARxAwsTfs3I0Ch2wB7DpWigxVWnwXtR
z1w5rClJvXz013uNMZsAsWwyzH83XIlntSqFazO2wqgFh24Dm/fuMDKqjBCXRWrS
EQ7Xs6vXoQs5U8+ArIHLX/E6e2MePmmostVfjJi33CAkU2mw2yu1WvWPgFNaoCM=
=BgnM
-----END PGP SIGNATURE-----