yahoo-eng-team team mailing list archive

[Colleen Murphy <colleen@xxxxxxxxxxx>]

*** This bug is a security vulnerability ***

Public security bug reported:

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.

** Affects: keystone
     Importance: High
         Status: Triaged


** Tags: security trusts

** Tags removed: trus
** Tags added: security trusts

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

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