Open Stack

This issue was fixed in the openstack/neutron 12.0.0.0rc1 release
candidate.

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