Open Stack

This is not a bug.  Trust ids are not secrets.  They can and are public
info.  They are no more secret than a role assignment ID.  Argh!

On Thu, Aug 15, 2019, 1:15 PM Colleen Murphy <colleen at gazlene.net>
wrote:

> I think changing the return code is the first step, done in
> https://review.opendev.org/676528 (we need to change tempest too). The
> rest of the fix is to move all of the authorization logic into policies
> (https://review.opendev.org/#/q/topic:trust-policies) and then to
> implement system scope and default roles for the trust policies
> (https://launchpad.net/bugs/1818850 https://launchpad.net/bugs/1818846).
>
> --
> You received this bug notification because you are subscribed to
> OpenStack Identity (keystone).
> Matching subscriptions: keystone-bugs
> 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:
>   Incomplete
>
> 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
>

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