Open Stack

I completely agree with Geroge on this.  You have a use case when
neutron fails to correctly isolate on multi-tenants networks.  This
"incomplete feature" set was never called  in documentation as a
possible trade off.  So if nothing you have an  known issue that causes
neutron not provide appropriate isolation under specific configurations,
in a trivially to reproduce manner.  This would lead to things that
would be at a minimum considered bugs and most likely vulnerabilities.

Without a patch this "incomplete feature" allows trivial man in the
middle attacks, taking vm's offline of any tenant at will, taking over
the metadata id,  from there one could easily change/spoof peoples
metadata including changing it to add credentials/users for other
tenants vm's.  This could also lead to someone breaking vm provisioning
(metadata/userdata) scripts for other tenants.   One could  also
trivially takeover the gateway for flat networked tenants allowing a vm
to see all the routed traffic on that network.  If one also managed to
spin up a vm on the shared public network that peoples "correctly
isolated" private l2 routers attach to one could also takeover
traffic/floating ip destined  to routers that neutron should be
handling.   I have seen on the mailing list people wanting to support
both private and shared networks so this is a completely plausible
configuration.

Re: comment #9.  Comment #8 specifically talks about back porting this
change to latest stable --- which would be kilo/juno - no? and previous
comments dealt more about handling this issue in the open as opposed to
behind closed doors (IE only the security team and people involved in
the fix can see the bug).  Kevin Bentons patch only works on OVS.  Last
time I checked ml2 supported more than just OVS.  Where this patch fixes
it no mater the switch technology being used.

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