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:
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?
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 tapdb545a8c- 8f DROP tapdb545a8c- 8f tapdb545a8c- 8f tapdb545a8c- 8f -i tapdb545a8c-8f --among-src fa:16:3e:84:cd:b4 -j RETURN tapdb545a8c- 8f -p ARP --arp-ip-src 192.0.2.5 -j ACCEPT
:neutronARP-
-A PREROUTING -i tapdb545a8c-8f -j neutronMAC-
-A PREROUTING -p ARP -i tapdb545a8c-8f -j neutronARP-
-A neutronMAC-
-A neutronARP-
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 bionic: ~# ebtables-save | grep newchain bionic: ~# ebtables -t nat -F newchain bionic: ~# ebtables-save | grep newchain bionic: ~# ebtables --version
root@jake-
:newchain DROP
root@jake-
root@jake-
:newchain DROP
root@jake-
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