[Openstack-security] [Bug 1732294] Re: Probable DOS in linuxbridge
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
** 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.
Probable DOS in linuxbridge
Status in neutron:
Status in OpenStack Security Advisory:
Status in OpenStack Security Notes:
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
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
We deployed a workaround to our own infrastructure but I believe
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: