Application credentials of other users can be deleted when knowing the ID

Since this report concerns a possible security risk, an incomplete
security advisory task has been added while the core security
reviewers for the affected project or projects confirm the bug and
discuss the scope of any vulnerability along with potential
solutions.

In the past, OpenStack's vulnerability managers have considered exploit scenarios requiring the malicious actor to guess or otherwise obtain version 4 UUIDs for resources to which they're not entitled as impractical and safe to discuss in public, class C1 in our report taxonomy:

https://security.openstack.org/vmt-process.html#incident-report-taxonomy

Are there unusual circumstances for this report which should require private discussion under embargo instead?

Not from our side.

C1 seems appropriate here, alongside making this public.

I have switched this bug to public, treating it as a security hardening opportunity pending further insights from reviewers.

Fix proposed to branch: master
Review: https://review.opendev.org/760972

This issue was fixed in the openstack/keystone 19.0.0.0rc1 release candidate.

Reviewed: https://review.opendev.org/c/openstack/keystone/+/769221
Committed: https://opendev.org/openstack/keystone/commit/6b739ffc337ad5491b027a4c2312bf3f461079c8
Submitter: "Zuul (22348)"
Branch: stable/ussuri

commit 6b739ffc337ad5491b027a4c2312bf3f461079c8
Author: Lance Bragstad <email address hidden>
Date: Mon Nov 2 17:22:49 2020 +0000

    Use app cred user ID in policy enforcement

    The application credential policies use the `rule:owner` policy to allow
    users to manage their own credentials. The policy engine pulled the
    user_id attribute from the request path instead of the actual
    application credential. This allowed for users to exploit the
    enforcement and view or delete application credentials they don't own.

    This commit attempts to resolve the issue by updating the flask
    parameters before they're translated to policy arguments and target
    data, prior to policy enforcement.

    Change-Id: I903d20fa41270499ca1c39d296120dd97cef5405
    Closes-Bug: 1901207
    (cherry picked from commit 2d7bf10a5a145ed3b6e34c3cb95e05fb7e33e0d1)
    (cherry picked from commit 80832de6ced534bccbf7cfe24a6a01c8262c1779)

Reviewed: https://review.opendev.org/c/openstack/keystone/+/769222
Committed: https://opendev.org/openstack/keystone/commit/9c879d46bf40f8a11e8033406bb1b8861baf3f51
Submitter: "Zuul (22348)"
Branch: stable/train

commit 9c879d46bf40f8a11e8033406bb1b8861baf3f51
Author: Lance Bragstad <email address hidden>
Date: Mon Nov 2 17:22:49 2020 +0000

    Use app cred user ID in policy enforcement

    The application credential policies use the `rule:owner` policy to allow
    users to manage their own credentials. The policy engine pulled the
    user_id attribute from the request path instead of the actual
    application credential. This allowed for users to exploit the
    enforcement and view or delete application credentials they don't own.

    This commit attempts to resolve the issue by updating the flask
    parameters before they're translated to policy arguments and target
    data, prior to policy enforcement.

    This commit also deviates slightly from backports to stable/ussuri,
    stable/victoria, and master (wallaby). This is because newer branches
    use `http.client` to assert status codes and in stable/train we are
    still using `http_client`. This change is functionally the same.

    Change-Id: I903d20fa41270499ca1c39d296120dd97cef5405
    Closes-Bug: 1901207
    (cherry picked from commit 2d7bf10a5a145ed3b6e34c3cb95e05fb7e33e0d1)
    (cherry picked from commit 80832de6ced534bccbf7cfe24a6a01c8262c1779)
    (cherry picked from commit 661bf6a1dca502f37b5da9995c45ba60581e5e97)

This issue was fixed in the openstack/keystone 16.0.2 release.

This issue was fixed in the openstack/keystone 17.0.1 release.

This issue was fixed in the openstack/keystone 18.1.0 release.