Discussed in IRC[0] - conclusion is this is a Valid bug but there is no reasonable attack vector (the data could be used in determining whom to attempt to gain access to, but does not provide any means of direct attack). The data is *NOT* intended to be public but is not really explicitly private/privileged either. The API Contract and current behavior is an acceptable (as long as it is documented in this bug) behavior to leave.
This may still warrant an OSSN outlining that the data is available but there is minimal or no risk. [0] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone /%23openstack-keystone.2019-08-16.log.html#t2019-08-16T21:36:28 ** Changed in: keystone Status: In Progress => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1840288 Title: Trusts GET API leaks existence information to unauthorized users Status in OpenStack Identity (keystone): Won't Fix Status in OpenStack Security Advisory: Won't Fix Bug description: The current implementation of the GET /v3/OS-TRUST/trusts/{trust_id} API leaks information about the existence of a trust to unauthorized users. If an authenticated user requests a trust that either does not exist or has no remaining uses, the returned response is a 404 regardless of whether the user is an admin or a trustor/trustee of the hypothetical (e.g. soft-deleted or used-up) trust. If the trust does exist but the user has no access to it, the returned response is a 403. If an attacker had some reasonable way of guessing or brute-forcing the UUID of a trust, they could use this leak to confirm its existence. A valid trust ID can then be used as part of a token request in combination with the trustee's credentials. The issue is here: https://opendev.org/openstack/keystone/src/commit/5beddfaddbb4c59d7a24fa1d7ff534da4c69ddc5/keystone/api/trusts.py#L149-L150 The current "identity:get_trust" default policy rule is "" which is all-permissive, and authorization is hardcoded in the trust controller code. To enforce the "only the trustor or trustee can GET this" rule, it does a lookup of the trust and doesn't catch a NotFound, thereby leaking it directly back to the requester. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1840288/+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
