Open Stack

We had proposed a blueprint for a fix to this bug:
https://blueprints.launchpad.net/neutron/+spec/arp-spoof-patch-ebtables

The fix was implemented and presented in the form of four patches. The
first two have been accepted and merged:

https://review.openstack.org/#/c/141130/
https://review.openstack.org/#/c/157097/

The two remaining patches, which would have integrated the patch with
the existing iptables code, however, were rejected:

https://review.openstack.org/#/c/157634/
https://review.openstack.org/#/c/158491/

Marc McClain suggested a different approach and did not want to have the
ebtables manager in its current form in the code. Since the remaining
two patches now do not have a chance of being accepted any more, I am
following Henry Gessau's recommendation: I am abandoning the remaining
patches and assign this bug to Marc, who will propose and implement a
different solution.

We will be happy to review the proposed new solution once we see a
blueprint. The acceptance requirement is simply to have a platform
independent solution, which prevents ARP cache poisoning on shared
networks, as described in the bug report.


 

** Changed in: ossa
     Assignee: Juergen Brendel (jbrendel) => (unassigned)

-- 
You received this bug notification because you are a member of OpenStack
Security, 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):
  In Progress
Status in OpenStack Security Advisories:
  Invalid
Status in OpenStack Security Notes:
  Fix Released

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