Open Stack

Reviewed:  https://review.openstack.org/520249
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=08108c41992a13c6959b717cccfe2b929e55d2eb
Submitter: Zuul
Branch:    master

commit 08108c41992a13c6959b717cccfe2b929e55d2eb
Author: Brian Haley <bhaley at redhat.com>
Date:   Wed Nov 15 19:24:22 2017 -0500

    Move Linuxbridge ARP spoofing to nat table PREROUTING chain
    
    It was found that adding ebtables rules to the filter table
    FORWARD chain could be vulnerable to a DoS attack.  Moving
    to the nat table PREROUTING chain should mitigate this as
    it is consulted prior to allowing the frame in.
    
    In order to make this work with upgrades, had to make the code
    detect and remove any old rules that might still exist in
    the filter table.  That can be removed after a cycle.
    
    Added some unit tests in addition to the existing functional
    tests.
    
    Change-Id: I87852b21db4404c58c83789cc267812030ac7d5f
    Closes-bug: #1732294


** Changed in: neutron
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1732294

Title:
  Probable DOS in linuxbridge

Status in neutron:
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix
Status in OpenStack Security Notes:
  New

Bug description:
  We experienced a DOS yesterday on a system (not openstack based) which
  would have been mitigated if a mac address whitelist in ebtables had
  occurred in the nat PREROUTING chain rather than the filter FORWARD
  chain.

  At least with kernel version 4.9, with rapidly cycling mac addresses
  the linux bridge appears to get bogged down in learning new MAC
  addresses if this is not explicitly turned off with brctl setageing
  <bridge> 0.

  We deployed a workaround to our own infrastructure but I believe
  https://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2/drivers/linuxbridge/agent/arp_protect.py#n158
  means that openstack has the same vulnerability.

  It should be possible to move all logic related to checking the input
  to the ebtables nat PREROUTING chain using the ebtables_nat module.

  To duplicate, in a VM on a host with bridged networking and mac
  spoofing protection in place, install dsniff and run:

  macof -i <ethernet device> -s <valid local IP> -d <valid remote IP> -n
  50000000 &> /dev/null

  Observe on the host that ksoftirqd usage goes to near 100% on one
  core, that 'perf top' will show br_fdb_update as taking significant
  resources, and that 'brctl showmacs <bridge>' will probably hang.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1732294/+subscriptions