yahoo-eng-team team mailing list archive

[Jeremy Stanley <fungi@xxxxxxxxxxx>]

Thanks for the heads up! It's our policy to go ahead and end embargoes
once an issue is publicly disclosed, so we'll move forward triaging this
as class C2 "A vulnerability, but not in OpenStack supported code, e.g.,
in a dependency" per our report taxonomy: https://security.openstack.org
/vmt-process.html#incident-report-taxonomy

Adding a new OSSN task in case the security note editors want to publish
something about this prior to or once the kernel fix is available.

** Description changed:

- This issue is being treated as a potential security risk under embargo.
- Please do not make any public mention of embargoed (private) security
- vulnerabilities before their coordinated publication by the OpenStack
- Vulnerability Management Team in the form of an official OpenStack
- Security Advisory. This includes discussion of the bug or associated
- fixes in public forums such as mailing lists, code review systems and
- bug trackers. Please also avoid private disclosure to other individuals
- not already approved for access to this information, and provide this
- same reminder to those who are made aware of the issue prior to
- publication. All discussion should remain confined to this private bug
- report, and any proposed fixes should be added to the bug as
- attachments.
- 
- --
- 
  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.

** Information type changed from Private Security to Public

** Tags added: security

** Also affects: ossn
   Importance: Undecided
       Status: New

** Changed in: ossa
       Status: New => Won't Fix

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1732294

Title:
  Probable DOS in linuxbridge

Status in neutron:
  New
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