Open Stack

Reviewed:  https://review.openstack.org/209708
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=1b73fbd70522a751f92120e776471c4deb159d0c
Submitter: Jenkins
Branch:    stable/juno

commit 1b73fbd70522a751f92120e776471c4deb159d0c
Author: Chet Burgess <cfb at metacloud.com>
Date:   Tue Aug 4 13:10:04 2015 -0700

    Add ARP spoofing protection for LinuxBridge agent
    
    This is a backport for the fix that went into master to address
    this bug.
    
    This patch adds ARP spoofing protection for the Linux Bridge
    agent based on ebtables.
    
    The protection is enabled and disabled with the same
    'prevent_arp_spoofing' agent config flag added for the OVS agent
    in I7c079b779245a0af6bc793564fa8a560e4226afe.
    
    The protection works by setting up an ebtables chain for each port
    and jumping all ARP traffic to that chain. The port-specific chains
    have a default DROP policy and then have allow rules installed that
    only allow ARP traffic with a source CIDR that matches one of the
    port's fixed IPs or an allowed address pair.
    
    Change-Id: I0b0e3b1272472385dff060897ecbd25e93fd78e7
    Closes-Bug: #1274034


** Tags added: in-stable-juno

-- 
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 neutron:
  Fix Released
Status in OpenStack Security Advisory:
  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