Comment 0 for bug 1938670

We are running an OpenStack cloud with linux bridge. We have found that, in certain conditions, ARP spoofing protection is not working as intended. This allows a user do bad things like spoof gratuitous ARP to DoS another user's virtual machine. More details below.

In an environment using linux bridge, neutron-linuxbridge-agent uses ebtables to prevent ARP spoofing. A list of typical ebtables rules for a VM looks like this:

 :neutronMAC-tapdb545a8c-8f DROP
 :neutronARP-tapdb545a8c-8f DROP
 -A PREROUTING -i tapdb545a8c-8f -j neutronMAC-tapdb545a8c-8f
 -A PREROUTING -p ARP -i tapdb545a8c-8f -j neutronARP-tapdb545a8c-8f
 -A neutronMAC-tapdb545a8c-8f -i tapdb545a8c-8f --among-src fa:16:3e:84:cd:b4 -j RETURN
 -A neutronARP-tapdb545a8c-8f -p ARP --arp-ip-src 192.0.2.5 -j ACCEPT

The neutronARP-xxx chain, however, has a problem during the creation of it. The source for that [1] looks like this:

 ebtables(['-N', vif_chain, '-P', 'DROP'])
 ebtables(['-F', vif_chain])

This creates a chain with default policy of DROP, and FLUSHes any existing rules.

However, we have found that in certain OS, the FLUSH reverts the default policy back to RETURN. E.g.

 root@jake-focal:~# eatables -t nat -N newchain -P DROP
 root@jake-focal:~# ebtables-save | grep newchain
 :newchain DROP
 root@jake-focal:~# ebtables -t nat -F newchain
 root@jake-focal:~# ebtables-save | grep newchain
 :newchain RETURN
 root@jake-focal:~# ebtables --version
 ebtables 1.8.4 (nf_tables)

The OSes that exhibit this issue seems to be OSes that uses ebtables-nft - Ubuntu Focal, CentOS Stream.

Ubuntu Bionic is fine. E.g.

 root@jake-bionic:~# ebtables -t nat -N newchain -P DROP
 root@jake-bionic:~# ebtables-save | grep newchain
 :newchain DROP
 root@jake-bionic:~# ebtables -t nat -F newchain
 root@jake-bionic:~# ebtables-save | grep newchain
 :newchain DROP
 root@jake-bionic:~# ebtables --version
 ebtables v2.0.10-4 (December 2011)

I have a patch for this, but as this is a security issue I am refraining from posting it up to OpenStack's Gerrit. Also, this might have been fixed in master, but it still affects Ussuri and Victoria. Please advise on what I should do next?

[1] https://opendev.org/openstack/neutron/src/branch/stable/ussuri/neutron/plugins/ml2/drivers/linuxbridge/agent/arp_protect.py#L135-L139