Open Stack

I grant that a trust ID on its own is not enough to get a token, and
that moreover if someone had a trustee's credentials or intercepted
token then that would already be enough to look up the trust, so the
trust UUID itself is not especially sensitive information. I would not
go as far as to say it is "public" information, and ideally we would
make this API consistent with our other APIs by enforcing RBAC first
before revealing the existence or nonexistence of a record in the
database. But it is not a severe enough leak to warrant changing the API
error response and so I agree with marking this Won't Fix.

-- 
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):
  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