Open Stack

So for man in the middle while I have not fully POC'd this.  The following does/should work:  
1.) Spin up a vm on a shared network with other tenants
2.) arpping for the gateway with your own mac or that of another vm.
3.) Add default gateway to your vm or another vm
3.) update the allowed ip address via allowed-address-pairs extension (which is enabled by default and is permited by the default rules) to add the default gateway to the your vm or another vm.  Allowed address pairs does zero bounds checking on ip's that you want to allow on a vm.  Also, until: https://github.com/openstack/neutron/commit/927399c011409b7d152b7670b896f15eee7d0db3 is backported is also a security issue, since by default anyone was allowed to hit the allowed address pairs extension.  Also this allows you to directly spoof other peoples mac/ips and allow this traffic though the anti-spoofing rules.
4.) Profit.  At this point you are garping for the default gateway and you have a vm that will allow traffic to pass.

Without allowed-address-pairs one would be limited to bringing down an
entire subnet/guest and/or seeing half of the network connectivity.  Is
a DoS also considered a security vulnerability?

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