[Openstack-security] [Bug 1840288] Re: Trusts GET API leaks existence information to unauthorized users
Morgan Fainberg
morgan.fainberg at gmail.com
Fri Aug 16 21:36:08 UTC 2019
The trust could be utilized as a vector of attack, knowing the existence
of a trust (and trustor/trustee) gives an additional target to utilize
for social engineering and otherwise. While this is a minimal security
concern overall, generally speaking information about a given grant is
not available to an unknown party (within Keystone). Trusts are not
intended to be public similarly they are not really intended to be
privileged information. I expect this should be consistency within
keystone where possible minimizing security exposure where possible.
If we grant that anyone should be able to see roles that someone has on
any project (provided they are logged in), I could see current behavior
with trusts to be the expected behavior.
This is not a critical security hole, but a chance to minimize
information that can be utilized by outside (but still valid keystone
users) parties not explicitly part of the delegation (Cloud Admin,
Domain/Project Admin*, Trustor, Trustee)
* Depending on policy configuration
--
You received this bug notification because you are a member of OpenStack
Security SIG, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1840288
Title:
Trusts GET API leaks existence information to unauthorized users
Status in OpenStack Identity (keystone):
In Progress
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
More information about the Openstack-security
mailing list