yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #92459
[Bug 1844712] Re: RA Leak on tenant network
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