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 -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
