yahoo-eng-team team mailing list archive

[Jeremy Stanley <1844712@xxxxxxxxxxxxxxxxxx>]

As annoying and disturbing as this bug is, we still years later lack
sufficient information to be able to reproduce and study the behavior in
order to even attempt to identify a root cause. Unless that situation
changes, it seems impractical to exploit at the very least. In
discussion between VMT members and others in the OpenStack Security SIG
during the 2023.1 PTG, we decided for now we'll treat it as class C1 per
our report taxonomy (though we're happy to revisit if anything changes):
https://security.openstack.org/vmt-process.html#report-taxonomy

** Changed in: ossa
       Status: Incomplete => Won't Fix

** Information type changed from Public Security to Public

** Tags added: security

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

Title:
  RA Leak on tenant network

Status in neutron:
  New
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  This morning we saw RA learned prefixes popping up on instances within
  the Limestone CI cloud nodepool tenant network. This was discovered
  because the instance hosting the openstack infra mirror at limestone,
  mirror.regionone.limestone.openstack.org, began failing to connect to
  external networks since it was sourcing outbound requests using non-
  routable IPv6 addresses. See http://paste.openstack.org/raw/777718/
  for output from the mirror instance. The only valid globally routable
  IPv6 addresses on Limestone are in 2607:ff68::/32, so the false
  addresses are easily identified there: 2003::f816:3eff:febd:b93/64 and
  2003::1:f816:3eff:febd:b93/64.

  I launched an instance to investigate the loss of connectivity and noticed that it also acted on these bogus RA's:
  http://paste.openstack.org/raw/777717/
  In addition, my instance learned 5 ipv6 default nexthops from RA's: http://paste.openstack.org/raw/777722/

  Among these, only fe80::f816:3eff:fe77:b05c is a valid nexthop on this
  network, hosted by a neutron HA router.

  I attempted to identify the remaining 4 MAC addresses by searching
  nova/neutron logs on the controller hosts and the compute hosts. I
  also searched the openstack mysql databases for hits on these MACs. I
  wasn't able to find any sign of these MAC addresses anywhere, so I
  wonder if these MACs might be generated by a neutron instance running
  within one of the gate jobs on the cloud. fungi noticed several test
  jobs are configured to use the 2003:: network
  http://codesearch.openstack.org/?q=2003%3A%3A.

  It is extremely unlikely that these invalid RA's leaked from outside
  the openstack environment since they are not physical hardware mac
  addresses, and also the virtual network where these RAs were observed
  is not bridged to the physical network whatsoever. Its only access to
  the outside world is through a neutron L3 HA router hosted on the
  controller hosts. All traffic between the instances and the
  controllers is transmitted over a neutron linuxbridge vxlan network.

  The cloud is a Rocky openstack cloud deployed by openstack-ansible.
  The entire configuration for this cloud is located at
  https://opendev.org/limestone/ci-cloud-config.

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