yahoo-eng-team team mailing list archive

[OpenStack Infra <2088986@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.opendev.org/c/openstack/neutron/+/935883
Committed: https://opendev.org/openstack/neutron/commit/fb75d3c4f185bb082f69c121090382d9eb803b94
Submitter: "Zuul (22348)"
Branch:    master

commit fb75d3c4f185bb082f69c121090382d9eb803b94
Author: Rodolfo Alonso Hernandez <ralonsoh@xxxxxxxxxx>
Date:   Thu Nov 21 11:55:37 2024 +0000

    Fix the tagging policy engine
    
    The service tagging policy engine should consider the parent resource or
    the upper parent resource project ID when checking the policies against
    the caller project ID.
    
    Before this patch, as introduced in [1], the target was incorrectly
    populated with the caller project ID instead of using the resource ID.
    
    [1]https://review.opendev.org/c/openstack/neutron/+/896509/13/neutron/extensions/tagging.py
    
    OSSA-2024-005 CVE-2024-53916
    
    Closes-Bug: #2088986
    Change-Id: Id7d0c8e7ba37993b1084519d05e7e2eac095b81b


** Changed in: neutron
       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/2088986

Title:
  [OSSA-2024-005] Authorization bypassed when setting tags on networks
  (CVE-2024-53916)

Status in neutron:
  Fix Released
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