Reviewed: https://review.opendev.org/c/openstack/ossa/+/936200
Committed:
https://opendev.org/openstack/ossa/commit/a1e1e2294c1a9365f5b02048a6f837c35458975f
Submitter: "Zuul (22348)"
Branch: master
commit a1e1e2294c1a9365f5b02048a6f837c35458975f
Author: Jay Faulkner <j...@jvf.cc>
Date: Mon Nov 25 12:14:27 2024 -0800
Add OSSA-2024-005 (CVE-2024-53916)
Closes-bug: #2088986
Change-Id: Ic107e4612e4803021c464b74e263dd774e7ee2e6
** Changed in: ossa
Status: In Progress => Fix Released
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2024-53916
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2088986
Title:
[OSSA-2024-005] Authorization bypassed when setting tags on networks
(CVE-2024-53916)
Status in neutron:
In Progress
Status in OpenStack Security Advisory:
Fix Released
Bug description:
An unprivileged tenant is able to change (add and clear) tags on
network objects which do not belong to the tenant, and this action is
not being subjected to the rule:update_network authorisation check.
Since the use of the tags attribute is defined locally, the security
impact of unauthorised tag modification can be anywhere from zero to
critical. A few hypothetical situations spring to mind:
1. If the OpenStack operator is using tags to map networks to VRFs, a tenant
could move an external network from a public Internet VRF to a private one
belonging to an unrelated tenant, thus gaining unauthorised access to the other
tenant's private networks.
2. Similarly, a tenant could move a shared external network from into a
non-existent VRF or remove the VRF mapping altogether, thus executing a DoS
attack impacting all other tenants using the same shared external network.
3. If tags is being used to control billing, e.g., by specifying which
customer account the network's bandwidth usage should be billed to, then the
tenant could possibly make the usage be incorrectly billed to another unrelated
tenant, or not billed at all.
This is easily reproduced with latest devstack, with all defaults. The
'demo' account are allowed to set the tags on all the pre-created
networks:
ubuntu@devstack-tore:~/devstack$ . stackrc
ubuntu@devstack-tore:~/devstack$ echo $OS_USERNAME
demo
ubuntu@devstack-tore:~/devstack$ openstack network set --tag pwnd shared
ubuntu@devstack-tore:~/devstack$ openstack network set --tag pwnd public
ubuntu@devstack-tore:~/devstack$ openstack network set --tag pwnd private
ubuntu@devstack-tore:~/devstack$
The expectation would be that the 'demo' user would only be allowed to
set the tags on the 'private' network, which is owned by the demo
project. For comparison, this is precisely how it works for setting
other attributes, like the description:
ubuntu@devstack-tore:~/devstack$ openstack network set --description pwnd
shared
ForbiddenException: 403: Client Error for url:
http://10.255.255.135:9696/networking/v2.0/networks/a75396a5-dc52-43a1-ba9d-ab7ff9fe2d6c,
rule:update_network is disallowed by policy
ubuntu@devstack-tore:~/devstack$ openstack network set --description pwnd
public
ForbiddenException: 403: Client Error for url:
http://10.255.255.135:9696/networking/v2.0/networks/b20d6975-9e6c-4911-b5cc-46278e0ac62e,
rule:update_network is disallowed by policy
ubuntu@devstack-tore:~/devstack$ openstack network set --description pwnd
private
ubuntu@devstack-tore:~/devstack$
The above commands resulted in:
ubuntu@devstack-tore:~/devstack$ openstack network show -c description -c
tags shared
+-------------+-------+
| Field | Value |
+-------------+-------+
| description | |
| tags | pwnd |
+-------------+-------+
ubuntu@devstack-tore:~/devstack$ openstack network show -c description -c
tags public
+-------------+-------+
| Field | Value |
+-------------+-------+
| description | |
| tags | pwnd |
+-------------+-------+
ubuntu@devstack-tore:~/devstack$ openstack network show -c description -c
tags private
+-------------+-------+
| Field | Value |
+-------------+-------+
| description | pwnd |
| tags | pwnd |
+-------------+-------+
The same behaviour was also observed on RDO 2024.1/OVN 24.03/AlmaLinux
9.
Best regards,
Tore Anderson
Redpill Linpro AS
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2088986/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
