Open Stack

Reviewed:  https://review.openstack.org/221364
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=b62b92da9b9dbba953573bc212279c719e08f3ef
Submitter: Jenkins
Branch:    master

commit b62b92da9b9dbba953573bc212279c719e08f3ef
Author: Cedric Brandily <zzelle at gmail.com>
Date:   Tue Sep 8 15:23:49 2015 +0000

    Remove ebtables_driver/manager dead code
    
    Previous changes[1] have been merged as enablers[2] to fix the bug
    1274034 but an alternative solution has been choosen and now we can
    consider the introduced code as dead code.
    
    This changes removes [2], associated tests and rootwrap filters.
    
    [1] I9ef57a86b1a1c1fa4ba1a034c920f23cb40072c0
        I3c66e92cbe8883dcad843ad243388def3a96dbe5
    [2] neutron.agent.linux.ebtables_driver
        neutron.agent.linux.ebtables_manager
    
    Closes-Bug: #1493422
    Related-Bug: #1274034
    Change-Id: I61e38fc0d8cf8e79252aabc19a70240be57e4a32

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