Bug 2129193 (CVE-2022-3277)

Summary: CVE-2022-3277 openstack-neutron: unrestricted creation of security groups
Product: [Other] Security Response Reporter: Nick Tait <ntait>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: chrisw, dalvarez, eglynn, jjoyce, lhh, mburns, mgarciac, ralonsoh, rhos-maint, scohen, spower, srevivo
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
An uncontrolled resource consumption flaw was found in openstack-neutron. This flaw allows a remote authenticated user to query a list of security groups for an invalid project. This issue creates resources that are unconstrained by the user's quota. If a malicious user were to submit a significant number of requests, this could lead to a denial of service.
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-12-10 02:13:21 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2129211, 2129213, 2129214, 2132257    
Bug Blocks: 2123777, 2175289    

Description Nick Tait 2022-09-22 20:44:11 UTC
Upstream bug description:
When a non-admin user tries to list security groups for project_id "None", Neutron creates a default security group for that project and returns an empty list to the caller.

To reproduce:

openstack --os-cloud devstack security group list --project None
openstack --os-cloud devstack-admin security group list

The API call that is made is essentially

GET /networking/v2.0/security-groups?project_id=None

The expected result would be an authorization failure, since normal users should not be allowed to list security groups for other projects.

Comment 1 Nick Tait 2022-09-22 22:59:21 UTC
Created openstack-neutron tracking bugs for this issue:

Affects: openstack-rdo [bug 2129211]

Comment 3 Rodolfo Alonso 2022-10-04 08:17:17 UTC
Hello:

Since [1], the OSC client checks the project ID before executing a command when listing the security groups. This patch is in the code since U/S version Queens (OSP13). This check has been replicated to other Network commands too.

This is the output when the related command is executed (using a OSP16.2 deployment):
  $ openstack security group list --project None
  No project with a name or ID of 'None' exists.


When an admin user calls the CLI script checks the existence of the project "None" before sending the command to the Neutron server. If the project does not exists, the CLI returns this error message.

If the user is a regular user and the project does not exist or can't be seen from this user, the CLI does not return anything (to avoid providing information to a unauthorized user):
  $ openstack security group list --project <non_existing_project>
  (empty line)
  $ openstack security group list --project <admin_project>
  (empty line)


Can you check when this is happening and what version are you using?

Regards.


[1]https://review.opendev.org/c/openstack/python-openstackclient/+/355405

Comment 7 errata-xmlrpc 2022-12-07 19:25:50 UTC
This issue has been addressed in the following products:

  Red Hat OpenStack Platform 16.2

Via RHSA-2022:8855 https://access.redhat.com/errata/RHSA-2022:8855

Comment 8 errata-xmlrpc 2022-12-07 20:27:06 UTC
This issue has been addressed in the following products:

  Red Hat OpenStack Platform 16.1

Via RHSA-2022:8870 https://access.redhat.com/errata/RHSA-2022:8870

Comment 9 Product Security DevOps Team 2022-12-10 02:13:18 UTC
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2022-3277

Comment 10 errata-xmlrpc 2023-01-25 12:29:53 UTC
This issue has been addressed in the following products:

  Red Hat OpenStack Platform 17.0

Via RHSA-2023:0275 https://access.redhat.com/errata/RHSA-2023:0275