Thanks for the analysis everyone! In addition to the points made, the VMT generally considers exploits requiring someone to know or guess the UUID associated with another tenant or another tenant's resources as a fairly low risk on its own, and bugs which leak the UUIDs of things to users who shouldn't have access to them as more serious.
Based on the above observations, this seems like an impractical vulnerability to exploit (class C1 in our taxonomy[*]) and might warrant a security note (OSSN)[**] if anyone is interested in writing one, but I don't think we'll issue an official advisory (OSSA). [*] https://security.openstack.org/vmt-process.html#report-taxonomy [**] https://wiki.openstack.org/wiki/Security/Security_Note_Process ** Description changed: - This issue is being treated as a potential security risk under - embargo. Please do not make any public mention of embargoed - (private) security vulnerabilities before their coordinated - publication by the OpenStack Vulnerability Management Team in the - form of an official OpenStack Security Advisory. This includes - discussion of the bug or associated fixes in public forums such as - mailing lists, code review systems and bug trackers. Please also - avoid private disclosure to other individuals not already approved - for access to this information, and provide this same reminder to - those who are made aware of the issue prior to publication. All - discussion should remain confined to this private bug report, and - any proposed fixes should be added to the bug as attachments. This - embargo shall not extend past 2024-05-21 and will be made - public by or on that date even if no fix is identified. - I have been looking into the possibility of sharing security groups cloud-wide. I found the following command "openstack network rbac create ...". But I expected from a security perspective, that only admins (== cloud operator) should be able to use this. I found out that as a user with the member role, i could also share security groups with a project as long as i know the name of the project. And not only that, I was also able to share a network, that can be found, when searching for external networks (It is a private network): ``` $ openstack network rbac create --target-project test-proj-2 --action access_as_shared --type security_group 44c6734a-baf7-4e90-8ba4-27001342d9ea +-------------------+--------------------------------------+ | Field | Value | +-------------------+--------------------------------------+ | action | access_as_shared | | id | 8f5ea6a4-adbe-4bfa-88af-5205853cf01c | | object_id | 44c6734a-baf7-4e90-8ba4-27001342d9ea | | object_type | security_group | | project_id | 8c59028a6e5144a78dfee2364d529070 | | target_project_id | test-proj-2 | +-------------------+--------------------------------------+ $ openstack network rbac create --target-project test-proj-2 --action access_as_external --type network test-net2 +-------------------+--------------------------------------+ | Field | Value | +-------------------+--------------------------------------+ | action | access_as_external | | id | 33ec8b68-49bd-49c8-8216-78619f4de557 | | object_id | 1bfab47d-b2f7-4c1b-a797-ba9d79121af7 | | object_type | network | | project_id | 8c59028a6e5144a78dfee2364d529070 | | target_project_id | test-proj-2 | +-------------------+--------------------------------------+ $ openstack network rbac list --long +-----------------------------------+----------------+------------------------------------+--------------------+ | ID | Object Type | Object ID | Action | +-----------------------------------+----------------+------------------------------------+--------------------+ | 84d026d9-619b-487a-825f- | security_group | a4c7070f-b7c8-499c-91aa- | access_as_shared | | c35c67869162 | | b6cf1c7cc1f1 | | | 8f5ea6a4-adbe-4bfa-88af- | security_group | 44c6734a-baf7-4e90-8ba4- | access_as_shared | | 5205853cf01c | | 27001342d9ea | | | 33ec8b68-49bd-49c8-8216- | network | 1bfab47d-b2f7-4c1b-a797- | access_as_external | | 78619f4de557 | | ba9d79121af7 | | +-----------------------------------+----------------+------------------------------------+--------------------+ ``` An admin can see the new "external network": ``` $ openstack network list --external +------------------------------+-----------+------------------------------+ | ID | Name | Subnets | +------------------------------+-----------+------------------------------+ | 1bfab47d-b2f7-4c1b-a797- | test-net2 | | | ba9d79121af7 | | | | 73edb86b-d7ab-4db3-82b7- | public | 3e0206bc-53c8-44ca-a0f1- | | 25fa8b012e40 | | 2c2548bba766, 84dffd43-6d7f- | | | | 4c2f-9180-8f0f0b83c9d4 | +------------------------------+-----------+------------------------------+ ``` From my perspective this could be used to advertise security groups or even networks to other projects and their users. What could be used in a social engineering way to get access to the network traffic or access to VMs. There is a policy, that can be changed to admin only access to this endpoint in the neutron policy file: ``` "create_rbac_policy": "rule:admin_only" "create_rbac_policy:target_tenant": "rule:admin_only" ``` I just wonder: this seems to be explicitly implemented this way. Is this behavior really wanted? In my opinion the default should be to only let administrators do such things as sharing networks or security groups. ** Information type changed from Private Security to Public ** Tags added: security ** Changed in: ossa Status: Incomplete => Won't Fix ** Also affects: ossn Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2054590 Title: Sharing of networks and security groups in OpenStack Status in neutron: Opinion Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: I have been looking into the possibility of sharing security groups cloud-wide. I found the following command "openstack network rbac create ...". But I expected from a security perspective, that only admins (== cloud operator) should be able to use this. I found out that as a user with the member role, i could also share security groups with a project as long as i know the name of the project. And not only that, I was also able to share a network, that can be found, when searching for external networks (It is a private network): ``` $ openstack network rbac create --target-project test-proj-2 --action access_as_shared --type security_group 44c6734a-baf7-4e90-8ba4-27001342d9ea +-------------------+--------------------------------------+ | Field | Value | +-------------------+--------------------------------------+ | action | access_as_shared | | id | 8f5ea6a4-adbe-4bfa-88af-5205853cf01c | | object_id | 44c6734a-baf7-4e90-8ba4-27001342d9ea | | object_type | security_group | | project_id | 8c59028a6e5144a78dfee2364d529070 | | target_project_id | test-proj-2 | +-------------------+--------------------------------------+ $ openstack network rbac create --target-project test-proj-2 --action access_as_external --type network test-net2 +-------------------+--------------------------------------+ | Field | Value | +-------------------+--------------------------------------+ | action | access_as_external | | id | 33ec8b68-49bd-49c8-8216-78619f4de557 | | object_id | 1bfab47d-b2f7-4c1b-a797-ba9d79121af7 | | object_type | network | | project_id | 8c59028a6e5144a78dfee2364d529070 | | target_project_id | test-proj-2 | +-------------------+--------------------------------------+ $ openstack network rbac list --long +-----------------------------------+----------------+------------------------------------+--------------------+ | ID | Object Type | Object ID | Action | +-----------------------------------+----------------+------------------------------------+--------------------+ | 84d026d9-619b-487a-825f- | security_group | a4c7070f-b7c8-499c-91aa- | access_as_shared | | c35c67869162 | | b6cf1c7cc1f1 | | | 8f5ea6a4-adbe-4bfa-88af- | security_group | 44c6734a-baf7-4e90-8ba4- | access_as_shared | | 5205853cf01c | | 27001342d9ea | | | 33ec8b68-49bd-49c8-8216- | network | 1bfab47d-b2f7-4c1b-a797- | access_as_external | | 78619f4de557 | | ba9d79121af7 | | +-----------------------------------+----------------+------------------------------------+--------------------+ ``` An admin can see the new "external network": ``` $ openstack network list --external +------------------------------+-----------+------------------------------+ | ID | Name | Subnets | +------------------------------+-----------+------------------------------+ | 1bfab47d-b2f7-4c1b-a797- | test-net2 | | | ba9d79121af7 | | | | 73edb86b-d7ab-4db3-82b7- | public | 3e0206bc-53c8-44ca-a0f1- | | 25fa8b012e40 | | 2c2548bba766, 84dffd43-6d7f- | | | | 4c2f-9180-8f0f0b83c9d4 | +------------------------------+-----------+------------------------------+ ``` From my perspective this could be used to advertise security groups or even networks to other projects and their users. What could be used in a social engineering way to get access to the network traffic or access to VMs. There is a policy, that can be changed to admin only access to this endpoint in the neutron policy file: ``` "create_rbac_policy": "rule:admin_only" "create_rbac_policy:target_tenant": "rule:admin_only" ``` I just wonder: this seems to be explicitly implemented this way. Is this behavior really wanted? In my opinion the default should be to only let administrators do such things as sharing networks or security groups. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2054590/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
