Open Stack

Re:  just that it was not a problem Neutron's anti-spoofing rules were
originally designed to solve (much in the same way that a you wouldn't
consider a helmet flawed just because it fails to protect your knees).

Considering this commit when allowed address pairs were added/refactored
and the name previous name of this function:
https://github.com/openstack/neutron/commit/b67b20832a5bfccd1bbf8d1e63ebcd7061856881

Or if thats not good enough - the original commit that added security group rules to begin with: 
https://github.com/openstack/neutron/commit/f14af5dc755706c7297a96fa504acdfe15ac1957#diff-65b266f9e013df37c4934f0b1007897cR168


The original function of that code piece was specifically called out to do ARP SPOOFING filtering/prevention.  It's just that the person who originally did it probably didn't realize that you cant correctly filter arp via iptables.  So lets call a spade a spade here.  Its not an "imperfect design", its not an "incomplete design", it not that "neutron or quantum didn't try to filter or have features to prevent arp spoofing/cache poisoning.  Its a bug going back since security groups were implemented in neutron(actually quantum).  This got masked by a few code refactors when allowed address pairs was added, but the intent to do arp filter since the "dawn of time" is clearly there.

So I would say based upon the code and the intent with the applied
rules, this is more of the case of complaining because the helmet that
you were wearing (that you were told is specifically suppose to protect
you in the event of something bad) failed to protect your head and the
kneepads that you were also wearing also failed to protect you knees.

Lets do the right thing here.   Backport the fix to the stable versions.
Admit that the protections we thought we original added 2+ years ago
failed to actually do what we thought they did.  And move on with bigger
and better problems.   Jeremy you even said in post #6 that if neutron
documentation or config options says it specifically implements code to
do the filter that it would be a vulnerability.  Well the original  code
says it was suppose to filter ARP spoofing, it doesn't.

-- 
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