yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #93586
[Bug 2054590] Re: Sharing of networks and security groups in OpenStack
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
