yahoo-eng-team team mailing list archive

[OpenStack Infra <1938670@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.opendev.org/c/openstack/ossa/+/804116
Committed: https://opendev.org/openstack/ossa/commit/5bfba3e739b9988206a51fc564a05cc32b23a791
Submitter: "Zuul (22348)"
Branch:    master

commit 5bfba3e739b9988206a51fc564a05cc32b23a791
Author: Jeremy Stanley <fungi@xxxxxxxxxxx>
Date:   Tue Aug 10 16:41:27 2021 +0000

    Add OSSA-2021-004 (CVE-2021-38598)
    
    Change-Id: I91b44e7fab3209170efd8dc594cb1b442ee48c2d
    Closes-Bug: #1938670


** Changed in: ossa
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1938670

Title:
  Linuxbridge ARP filter bypass on Netfilter platforms (CVE-2021-38598)

Status in neutron:
  Confirmed
Status in OpenStack Security Advisory:
  Fix Released

Bug description:
  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

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1938670/+subscriptions