Open Stack

Thanks for the feedback Mathieu, and I absolutely agree. It's meant to
be a mitigation approach as it only filters L3 and prevents the
malicious VM from actually gathering any data. They can still DoS the L2
segment by hijacking traffic destined for the gateway (or any other IP
for that matter), and L2 filtering (which the ebtables approach would
accomplish) is the only way to stop that aspect of it.

There are also a few other things we're looking at to help beef up this
area. One thing would be working to implement more robust port-security
like features in the ovs-plugin-agent. As of OVS 1.10 they've
implemented a drop_spoofed_arp flow action, which, while wouldn't
necessarily address this specific issue, probably couldn't hurt to put
on ports.

Regardless, we're doing some more testing in house to make sure it
doesn't have any unintended effects, but assuming that all goes well
I'll work on getting this patch into havana/icehouse. The processing
overhead of one more chain should have a miniscule effect on throughput,
and it can't hurt to have another validation that the packets are indeed
coming and going to the correct place.

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1274034

Title:
  Neutron firewall anti-spoofing does not prevent ARP poisoning

Status in OpenStack Neutron (virtual network service):
  Triaged
Status in OpenStack Security Advisories:
  Invalid

Bug description:
  The neutron firewall driver 'iptabes_firawall' does not prevent ARP cache poisoning.
  When anti-spoofing rules are handled by Nova, a list of rules was added through the libvirt network filter feature:
  - no-mac-spoofing
  - no-ip-spoofing
  - no-arp-spoofing
  - nova-no-nd-reflection
  - allow-dhcp-server

  Actually, the neutron firewall driver 'iptabes_firawall' handles only
  MAC and IP anti-spoofing rules.

  This is a security vulnerability, especially on shared networks.

  Reproduce an ARP cache poisoning and man in the middle:
  - Create a private network/subnet 10.0.0.0/24
  - Start 2 VM attached to that private network (VM1: IP 10.0.0.3, VM2: 10.0.0.4)
  - Log on VM1 and install ettercap [1]
  - Launch command: 'ettercap -T -w dump -M ARP /10.0.0.4/ // output:'
  - Log on too on VM2 (with VNC/spice console) and ping google.fr => ping is ok
  - Go back on VM1, and see the VM2's ping to google.fr going to the VM1 instead to be send directly to the network gateway and forwarded by the VM1 to the gw. The ICMP capture looks something like that [2]
  - Go back to VM2 and check the ARP table => the MAC address associated to the GW is the MAC address of VM1

  [1] http://ettercap.github.io/ettercap/
  [2] http://paste.openstack.org/show/62112/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1274034/+subscriptions