Manila's share networks API exposes privileged network information

[Goutham Pacha Ravi]

When creating share networks from neutron networks, a non-privileged project user can gather privileged neutron network information from the share networks API.

Neutron network:

(demo@overcloud) [stack@undercloud-0 ~]$ neutron net-show demo-net
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
+-------------------------+--------------------------------------+
| Field | Value |
+-------------------------+--------------------------------------+
| admin_state_up | True |
| availability_zone_hints | |
| availability_zones | nova |
| created_at | 2019-04-11T19:33:11Z |
| description | |
| id | 1e83e04c-fb5a-4985-b1a1-eb2044c447c5 |
| ipv4_address_scope | |
| ipv6_address_scope | |
| l2_adjacency | True |
| mtu | 1500 |
| name | demo-net |
| port_security_enabled | True |
| project_id | 65bbd70550c44bd08e1e37691e5d5c41 |
| qos_policy_id | |
| revision_number | 3 |
| router:external | False |
| shared | False |
| status | ACTIVE |
| subnets | 4a46720e-c889-417b-b27d-1568473a537d |
| tags | |
| tenant_id | 65bbd70550c44bd08e1e37691e5d5c41 |
| updated_at | 2019-04-11T19:33:43Z |
+-------------------------+--------------------------------------+

(demo@overcloud) [stack@undercloud-0 ~]$ neutron subnet-show demo-subnet
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
+-------------------+--------------------------------------------------+
| Field | Value |
+-------------------+--------------------------------------------------+
| allocation_pools | {"start": "172.20.0.2", "end": "172.20.255.254"} |
| cidr | 172.20.0.0/16 |
| created_at | 2019-04-11T19:33:43Z |
| description | |
| dns_nameservers | 10.0.0.1 |
| enable_dhcp | True |
| gateway_ip | 172.20.0.1 |
| host_routes | |
| id | 4a46720e-c889-417b-b27d-1568473a537d |
| ip_version | 4 |
| ipv6_address_mode | |
| ipv6_ra_mode | |
| name | demo-subnet |
| network_id | 1e83e04c-fb5a-4985-b1a1-eb2044c447c5 |
| project_id | 65bbd70550c44bd08e1e37691e5d5c41 |
| revision_number | 0 |
| service_types | |
| subnetpool_id | |
| tags | |
| tenant_id | 65bbd70550c44bd08e1e37691e5d5c41 |
| updated_at | 2019-04-11T19:33:43Z |
+-------------------+--------------------------------------------------+

Manila share network:

(demo@overcloud) [stack@undercloud-0 ~]$ manila share-network-show demo-sharenet
+-------------------+--------------------------------------+
| Property | Value |
+-------------------+--------------------------------------+
| network_type | vlan |
| name | demo-sharenet |
| segmentation_id | 1085 |
| created_at | 2019-04-11T19:37:07.000000 |
| neutron_subnet_id | 4a46720e-c889-417b-b27d-1568473a537d |
| updated_at | 2019-04-11T19:41:51.000000 |
| mtu | 1500 |
| gateway | 172.20.0.1 |
| neutron_net_id | 1e83e04c-fb5a-4985-b1a1-eb2044c447c5 |
| ip_version | 4 |
| cidr | 172.20.0.0/16 |
| project_id | 65bbd70550c44bd08e1e37691e5d5c41 |
| id | 7242d33b-53dc-4718-ba82-821ae68c4c9f |
| description | None |
+-------------------+--------------------------------------+

[Jeremy Stanley (fungi)]

So I can better understand the risks implicated in this report, can you explain the circumstances under which someone might create a "non-privileged project user" and which parts of the "share networks API" output are sensitive? Also what might such a user be able to do once obtaining this data?

[Goutham Pacha Ravi (gouthamr)]

The two privileged fields are "network_type" and "segmentation_id". These fields are protected by neutron policy [1] and they default to keystone user role with 'rule:admin_only'. I am unsure if this information can be used to exploit OpenStack services or users' data.

A user who has been denied access to this information by the cloud administrator (by virtue of policy) can use the share networks API to designate a neutron network as a manila share network, and gather the hidden details of the neutron share network; thereby working around the security cover of the Neutron API.

[1] https://opendev.org/openstack/neutron/src/commit/05d93684fb44de3d869d23a65c5c18f6af54ee2f/neutron/conf/policies/network.py#L78-L95

[Jeremy Stanley (fungi)]

Okay, so to clarify further, the Manila API has privileged access to data provided by the Neutron API and is either unaware as to which pieces are restricted by admin policy or is able to find out but has not implemented a comparable filter... or is it that Manila is performing the related Neutron query with its service credentials when it should be proxying the user's credentials for this particular purpose?

Alternatively, is it expected that operators should set similar policy filters in both Neutron and Manila to avoid this condition, but that it's not clearly documented?

[Goutham Pacha Ravi (gouthamr)]

Thanks for your insightful analysis and questions on this bug.

Manila is performing the neutron queries with its service credentials. Internally, it needs the information that it is incidentally exposing to end users.

Currently there is no fine-grained policy to isolate fields with the share networks API. That would be a good way to fix this bug. We could specify the default rule to match that of neutron.

[Tom Barron (tpb)]

Goutham, is there any use case at all for a manila user, even a manila admin, actually *needing* to get the network type or segmentation id of an underlying neutron network via the manila share-network api rather than via the neutron api itself?

I'm inclined to think the answer is no and that we should simply remove these fields from the manila share-network view builder altogether rather than having manila policy control their display. Neutron owns these fields, not manila, so neutron policy should have exclusive control of who can view them.

[Tom Barron (tpb)]

No known exploits based on this information leak but we should fix soon and backport the fix.

[Tom Barron (tpb)]

suggested fix

[Jeremy Stanley (fungi)]

Tom's patch attached to comment #7 seems like a clean solution, though does removal of these two keys from the response for the /share-networks method constitute a substantive, backward-incompatible API change?

[Tom Barron (tpb)]

> does removal of these two keys from the response for the /share-networks method constitute a substantive, backward-incompatible API change?

I think it is backward-incompatible and a (hypothetical) preexisting script that depends on getting these values from the manila api will break. But returning the values conditional on manila policy will also break some such scripts (assume the hypothetical scripts weren't running as admin) or allow leaking admin-only neutron info if the cloud admin does not set the manila policy to match neutron's. Using neutron policy in manila itself to control exposure of the fields would avoid ever leaking the info but seems messy and in any case will not maintain 100% backwards compatability with current behavior.

So I come back to the question whether there is any genuine use case for getting these two values from manila rather than from their owner, neutron. If not, then I think manila should mea culpa and quit the bad behavior rather than maintaining compatability at the cost of continuing to misbehave.

[Tony Breeds (o-tony)]

I'd rather see this handled via policy but .... In other projects we've added a deprecated config option that defaults to hiding data on master. Then on stable backports the default can be switcheed to leavinging the proviledged data visible (if desred) but the operator/admin has the ability to select either way on all branches and is given an explict heads up that the ability to get this data is going away and will need to update scripts accordingly.

Yes it's more code, yes it's somewhat "ugly" but we're not second guessing operators and also not breaking the existing API.

[Jeremy Stanley (fungi)]

Based on Tom's comment a year ago, there were no known ways to exploit this unintended information access. If this is still the case, it seems like the bug should probably be switched to public lest it get forgotten.

[Jeremy Stanley (fungi)]

Since it's been well over a year with no objections, I'm switching this report to public now.

[Jeremy Stanley (fungi)]

Based on prior discussion, I've also added a won't fix advisory task for the VMT and tagged it as a potential security hardening opportunity.

[Vida Haririan (vhariria)]

Hi Archana, Can you please provide an update on this bug.

[Vida Haririan (vhariria)]

See additional discussions at https://meetings.opendev.org/meetings/manila/2022/manila.2022-06-09-15.00.log.html

[Archana Kumari (archanaserver)]

Hi Vida,

Apologies for taking it so long. I'm currently facing some issues in my
devstack env. I'll fix it up soon and get back on this bug to work on it.

But I want to mention that if this is on your priority list, you
may unassign me for now. I'll be happy to take this(if still not resolved)
or another one later on :)

Thank you.

On Thu, Jun 9, 2022 at 9:31 PM Vida Haririan <email address hidden>
wrote:

> See additional discussions at
>
> https://meetings.opendev.org/meetings/manila/2022/manila.2022-06-09-15.00.log.html
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1824442
>
> Title:
> Manila's share networks API exposes privileged network information
>
> Status in OpenStack Shared File Systems Service (Manila):
> Confirmed
> Status in OpenStack Security Advisory:
> Won't Fix
>
> Bug description:
> When creating share networks from neutron networks, a non-privileged
> project user can gather privileged neutron network information from
> the share networks API.
>
>
> Neutron network:
>
>
> (demo@overcloud) [stack@undercloud-0 ~]$ neutron net-show demo-net
> neutron CLI is deprecated and will be removed in the future. Use
> openstack CLI instead.
> +-------------------------+--------------------------------------+
> | Field | Value |
> +-------------------------+--------------------------------------+
> | admin_state_up | True |
> | availability_zone_hints | |
> | availability_zones | nova |
> | created_at | 2019-04-11T19:33:11Z |
> | description | |
> | id | 1e83e04c-fb5a-4985-b1a1-eb2044c447c5 |
> | ipv4_address_scope | |
> | ipv6_address_scope | |
> | l2_adjacency | True |
> | mtu | 1500 |
> | name | demo-net |
> | port_security_enabled | True |
> | project_id | 65bbd70550c44bd08e1e37691e5d5c41 |
> | qos_policy_id | |
> | revision_number | 3 |
> | router:external | False |
> | shared | False |
> | status | ACTIVE |
> | subnets | 4a46720e-c889-417b-b27d-1568473a537d |
> | tags | |
> | tenant_id | 65bbd70550c44bd08e1e37691e5d5c41 |
> | updated_at | 2019-04-11T19:33:43Z |
> +-------------------------+--------------------------------------+
>
>
> (demo@overcloud) [stack@undercloud-0 ~]$ neutron subnet-show demo-subnet
> neutron CLI ...

[Vida Haririan (vhariria)]

Hi Archana,

Thanks for getting back to me. The bug is targeted to z-3, we will discuss
in the weekly IRC meeting.

Thanks,
Vida

On Mon, Jun 20, 2022 at 2:50 PM Archana Kumari <email address hidden>
wrote:

> Hi Vida,
>
> Apologies for taking it so long. I'm currently facing some issues in my
> devstack env. I'll fix it up soon and get back on this bug to work on it.
>
> But I want to mention that if this is on your priority list, you
> may unassign me for now. I'll be happy to take this(if still not resolved)
> or another one later on :)
>
> Thank you.
>
> On Thu, Jun 9, 2022 at 9:31 PM Vida Haririan <email address hidden>
> wrote:
>
> > See additional discussions at
> >
> >
> https://meetings.opendev.org/meetings/manila/2022/manila.2022-06-09-15.00.log.html
> >
> > --
> > You received this bug notification because you are a bug assignee.
> > https://bugs.launchpad.net/bugs/1824442
> >
> > Title:
> > Manila's share networks API exposes privileged network information
> >
> > Status in OpenStack Shared File Systems Service (Manila):
> > Confirmed
> > Status in OpenStack Security Advisory:
> > Won't Fix
> >
> > Bug description:
> > When creating share networks from neutron networks, a non-privileged
> > project user can gather privileged neutron network information from
> > the share networks API.
> >
> >
> > Neutron network:
> >
> >
> > (demo@overcloud) [stack@undercloud-0 ~]$ neutron net-show demo-net
> > neutron CLI is deprecated and will be removed in the future. Use
> > openstack CLI instead.
> > +-------------------------+--------------------------------------+
> > | Field | Value |
> > +-------------------------+--------------------------------------+
> > | admin_state_up | True |
> > | availability_zone_hints | |
> > | availability_zones | nova |
> > | created_at | 2019-04-11T19:33:11Z |
> > | description | |
> > | id | 1e83e04c-fb5a-4985-b1a1-eb2044c447c5 |
> > | ipv4_address_scope | |
> > | ipv6_address_scope | |
> > | l2_adjacency | True |
> > | mtu | 1500 |
> > | name | demo-net |
> > | port_security_enabled | True |
> > | project_id | 65bbd70550c44bd08e1e37691e5d5c41 |
> > | qos_policy_id | |
> > | revision_number | 3 |
> > | router:external | False |
> > | shared | False |
> > | status | ACTIVE |
> > | subnets | 4a46720e-c889-417b-b27d-1568473a537d |
> > | tags | ...

[Vida Haririan (vhariria)]

See additional discussions at https://meetings.opendev.org/meetings/manila/2022/manila.2022-06-23-15.00.log.html

[Goutham Pacha Ravi (gouthamr)]

Fix proposed to branch: master
    https://review.opendev.org/c/openstack/manila/+/849015

[Vida Haririan (vhariria)]

Additional comments at https://meetings.opendev.org/meetings/manila/2022/manila.2022-10-13-15.00.log.html

[Vida Haririan (vhariria)]

See additional related discussions at https://meetings.opendev.org/meetings/manila/2023/manila.2023-07-20-15.00.log.html

[Vida Haririan (vhariria)]

See additional related discussions at https://meetings.opendev.org/meetings/manila/2024/manila.2024-01-11-15.00.log.html