Comment 9 for bug 1732294

I'd recommend deploying the mitigation of moving the mac filtering rules to the ebtables nat PREROUTING chain rather than relying on a kernel fix.

On 11/15/2017 12:35 PM, Jeremy Stanley wrote:
> 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
>