[OSSA-2020-004] Keystone V3 /credentials endpoint policy logic allows to change credentials owner or target project ID (CVE-2020-12691)

[kay]

"_build_target_enforcement" function checks only for "credential_id": https://github.com/openstack/keystone/blob/7bb6314e40d6947294260324e84a58de191f8609/keystone/api/credentials.py#L38

Thus even having a '"identity:update_credential": "rule:cloud_admin or (user_id:%(target.credential.user_id)s)"' policy doesn't prevent a malicious user to create an EC2 credential, then change its owner and project ID, e.g.:

curl -X PATCH https://keystone/v3/credentials/3c2b3265350c6da3a18a143fbe975ca4a8ed88a6f8c6dacc2494a5c1287ba66f -H 'Accept: application/json' -H 'Content-Type: application/json' -H "X-Auth-Token: ***" -d'{
  "credential": {
    "project_id": "_target_project_id_",
    "user_id": "_target_user_id_"
  }
}'

Additionally it is possible to Create a credential with any existing project_id, though it doesn't have a serious security issue, e.g.:

{
  "credential": {
    "blob": "{\"access\": \"ffe6fc21b47c4d87befc95ad070c3b7a\", \"secret\": \"530196cd097e4a7ca9df7258aa89ff0e\", \"trust_id\": null}",
    "id": "3c2b3265350c6da3a18a143fbe975ca4a8ed88a6f8c6dacc2494a5c1287ba66f",
    "project_id": "_any_project_id_",
    "type": "ec2",
    "user_id": "_my_user_id_"
  }
}

[Jeremy Stanley (fungi)]

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.

[kay (kay-diam)]

In case, when "/credentials" endpoint is used to store a secret for TOTP (Time-based One-time Password), an attacker can set a TOTP secret for a victim user and it will be used to verify TOTP "passcode" along with all "totp" secrets, associated with a victim user.

[Colleen Murphy (krinkle)]

Verified. This is a critical issue as it allows any authenticated user to escalate to admin privileges. However, it is mitigated somewhat by the fact that the attacker needs to know or guess the UUID of the admin user and admin project, or the UUIDs of the user and project they are trying to impersonate.

[Colleen Murphy (krinkle)]

Patch attached. Currently running tempest and unit tests on it locally.

[Lance Bragstad (lbragstad)]

The proposed patch in comment #4 looks good and the unit test covers the exposed behavior.

[Gage Hugo (gagehugo)]

Thanks cmurphy for the quick fix, looks good and works for me locally.

With the verification here and fix, this is looking like a Class A vulnerability according to the VMT taxonomy[0]. Even with the requirement to know/guess UUIDs, this looks to be something that is exploitable by any authenticated user.

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

[Kristi Nikolla (knikolla)]

Patch in #4 looks good and unit test covers the issue. Was able to reproduce the bug local.

[Colleen Murphy (krinkle)]

Tempest and py37 unit tests pass for me locally. We will need to backport this to all supported releases. I have backports prepared, but we should wait for the keystone stable/stein branch to be unblocked before proposing them[0].

[0] https://review.opendev.org/720053

[kay (kay-diam)]

Hi Colleen. Could you also add a protection and unit test for create action? It is not so serious, but would be great to have.

As I mentioned in original ticket it is possible to create EC2 credentials with any existing projectID, even if it is a domainID:

curl -X POST https://keystone/v3/credentials -H 'Accept: application/json' -H 'Content-Type: application/json' -H "X-Auth-Token: ***" -d'{
  "credential": {
    "blob": "{\"access\": \"ffe6fc21b47c4d87befc95ad070c3b7a\", \"secret\": \"530196cd097e4a7ca9df7258aa89ff0e\", \"trust_id\": null}",
    "id": "3c2b3265350c6da3a18a143fbe975ca4a8ed88a6f8c6dacc2494a5c1287ba66f",
    "project_id": "_any_project_id_",
    "type": "ec2",
    "user_id": "_my_user_id_"
  }
}'

This credential won't be useful, but it would be great to have this protection.

[Colleen Murphy (krinkle)]

Protecting the POST case is more complicated because not all credential types use project_id and so the credentials policy only checks against the credential's owner, not their scope. Since this behavior is longstanding and can't be exploited to elevate the user's privileges, I'm inclined not to fix it.

[Jeremy Stanley (fungi)]

Since exploiting this depends on the attacker obtaining a UUID to which they should not normally have access, the VMT would typically consider this a class C1 report:

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

As such, it shouldn't warrant the overhead of an embargo process and would be fine finishing in public instead. Does anyone disagree with that assessment?

[Jeremy Stanley (fungi)]

Oh, now I see Gage's suggestion to treat it as a class A report instead. Gage, what's the scenario where an authenticated user can exploit this without access to the victim's UUID?

[Gage Hugo (gagehugo)]

I believe I was thinking that an authenticated user would be able to guess easier than a remote non-authenticated user. I'm fine with classifying this as C1 since it really does depend on UUID guessing.

[kay (kay-diam)]

In certain OpenStack environments user listing is allowed. As for the project IDs, users just post them in chats/github and don't think it is a secret. I'd not call it "guessing".

[Colleen Murphy (krinkle)]

Resource UUIDs are often not as carefully protected as other secret information. We have already set a precedent[0] that UUIDs are effectively public.

[0] https://bugs.launchpad.net/keystone/+bug/1840288

[Kristi Nikolla (knikolla)]

In our environment, we allow users with project_admin role to list people in their project. If a user with an admin role is part of the project of a malicious user (maybe to help with some debugging, or an inherited role), this would allow the malicious user to know the UUID of the admin user.

[Jeremy Stanley (fungi)]

Since it's been suggested that account UUIDs are generally available to untrusted users in some environments, I concur that this is better handled as a class A report and continuing the embargo is unfortunately warranted.

The UUID guessing guidance was added as an example for the C1 report classification in 2015 via https://review.openstack.org/255476 following a rash of theoretical vulnerabilities in that vein, but several recent examples have made it clear that some of objects in various services' APIs are keyed with UUIDs which are not safeguarded or we otherwise don't position this information as sensitive in obvious ways. As such, I've proposed https://review.opendev.org/720291 to remove this example from the OpenStack VMT's report taxonomy.

[kay (kay-diam)]

There are at least two use cases, when project admin user or barbican secret owner needs to know user ID (in certain cases they are provisioned automatically, e.g. by LDAP):
* assign a project role to this user, so he can access the project: https://docs.openstack.org/api-ref/identity/v3/?expanded=assign-role-to-user-on-project-detail#assign-role-to-user-on-project* fine grained barbican ACL permissions: https://docs.openstack.org/barbican/latest/api/reference/acls.html

Therefore it is not clear, whether user IDs or project IDs have to be considered as sensitive.

[Colleen Murphy (krinkle)]

Updated release notes in patch to include bug reference

[Colleen Murphy (krinkle)]

Is a CVE being requested for this? How can we move this forward?

[Gage Hugo (gagehugo)]

If we agree that this should be considered a Class A, I can write up an impact description for this.

[Gage Hugo (gagehugo)]

First draft below, please review:

Assuming that this affects all currently maintained releases of keystone.

Title: Credentials endpoint policy logic allows changing credential owner and target project ID
Reporter: kay
Products: Keystone
Affects: <15.0.1, ==16.0.0

Description:
kay reported a vulnerability in Keystone's EC2 credentials API. Any authenticated user could create an EC2 credential for themselves for a project that they have a specified role on, then perform an update to the credential user and project, allowing them to masquerade as another user. This potentially allows the malicious user to act as the admin on a project another user has the admin role on.

[Colleen Murphy (krinkle)]

> This potentially allows the malicious user to act as the admin on a project another user has the admin role on

... which in many cases can effectively grant the user global admin privileges.

[Gage Hugo (gagehugo)]

Updated, please review:

Title: Credentials endpoint policy logic allows changing credential owner and target project ID
Reporter: kay
Products: Keystone
Affects: <15.0.1, ==16.0.0

Description:
kay reported a vulnerability in Keystone's EC2 credentials API. Any authenticated user could create an EC2 credential for themselves for a project that they have a specified role on, then perform an update to the credential user and project, allowing them to masquerade as another user. This potentially allows the malicious user to act as the admin on a project another user has the admin role on, which can effectively grant the user global admin privileges.

[Colleen Murphy (krinkle)]

lgtm

[Jeremy Stanley (fungi)]

Gage's impact description in comment #24 works for me, I think we're set to get a CVE request rolling for this one and propose a disclosure timeline once the stable branch backports are confirmed viable.

[Gage Hugo (gagehugo)]

Could we get a patch for Stein/Train for this as well?

Waiting on a response for the CVE.

I'd like to propose next Tuesday (May 5th) as the proper disclosure date as well for this. Does that sound reasonable?

[Jeremy Stanley (fungi)]

May 5 disclosure should work as long as we send a downstream stakeholder notification with the patches for this no later than tomorrow (Friday, May 1).

[Jeremy Stanley (fungi)]

In retrospect, what with the tight timeline and this being a major holiday weekend for much of the World, let's push the advisory date to Wednesday May 6.

[Gage Hugo (gagehugo)]

May 6th works, we will still send out the embargo notification today.

[Gage Hugo (gagehugo)]

Embargo email sent.

[Nick Tait (nickthetait)]

I support Class A for this. Eagerly awaiting CVE assignment. Simplified the description a little, you are welcome to use this:

kay reported a vulnerability in Keystone's EC2 credentials API. Any authenticated user could create an EC2 credential in a project that they have a specified role on, then modify the credential user and project, allowing them to masquerade as another user. This may enable a malicious user to escalate themselves as an admin which (in some environments) is equivalent to gaining global admin privileges.

[Colleen Murphy (krinkle)]

I've reworked this patch to include fixes for bug 1872733, bug 1872735 and bug 1872755 and to resolve the merge conflict arising from the fix for bug 1872737. These patches are independently appliable but they won't pass unit tests without also applying the fix for 1873290. I've attached them on bug 1872735.

In validating the new version I noticed an error in the solution for this bug, attaching the diff here.

[Gage Hugo (gagehugo)]

The embargo for this bug has expired, we will be making public and fixes will be available in gerrit here shortly.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/ussuri
Review: https://review.opendev.org/725888

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/train
Review: https://review.opendev.org/725891

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/stein
Review: https://review.opendev.org/725893

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/rocky
Review: https://review.opendev.org/725895

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/725912
Committed: https://git.openstack.org/cgit/openstack/ossa/commit/?id=2548f46b0aff357f6c953b30179b4d8e151e4236
Submitter: Zuul
Branch: master

commit 2548f46b0aff357f6c953b30179b4d8e151e4236
Author: Gage Hugo <email address hidden>
Date: Wed May 6 10:57:15 2020 -0500

    Add OSSA-2020-004 (CVEs Pending)

    Change-Id: Ide28e91b184edab45d22c47661ad6bb6003dd244
    Closes-Bug: #1872735
    Closes-Bug: #1872733

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/pike
Review: https://review.opendev.org/726046

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/725888
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=2f2736ebb267c757ad77fcf25ee0aaeefab2a09d
Submitter: Zuul
Branch: stable/ussuri

commit 2f2736ebb267c757ad77fcf25ee0aaeefab2a09d
Author: Colleen Murphy <email address hidden>
Date: Tue Apr 14 16:47:44 2020 -0700

    Fix security issues with EC2 credentials

    This change addresses several issues in the creation and use of EC2/S3
    credentials with keystone tokens.

    1. Disable altering credential owner attributes or metadata

    Without this patch, an authenticated user can create an EC2 credential
    for themself for a project they have a role on, then update the
    credential to target a user and project completely unrelated to them. In
    the worst case, this could be the admin user and a project the admin
    user has a role assignment on. A token granted for an altered credential
    like this would allow the user to masquerade as the victim user. This
    patch ensures that when updating a credential, the new form of the
    credential is one the acting user has access to: if the system admin
    user is changing the credential, the new user ID or project ID could be
    anything, but regular users may only change the credential to be one
    that they still own.

    Relatedly, when a user uses an application credential or a trust to
    create an EC2 credential, keystone automatically adds the trust ID or
    application credential ID as metadata in the EC2 access blob so that it
    knows how the token can be scoped when it is used. Without this patch, a
    user who has created a credential in this way can update the access blob
    to remove or alter this metadata and escalate their privileges to be
    fully authorized for the trustor's, application credential creator's, or
    OAuth1 access token authorizor's privileges on the project. This patch
    fixes the issue by simply disallowing updates to keystone-controlled
    metadata in the credential.

    2. Respect token roles when creating EC2 credentials

    Without this patch, a trustee, an application credential user, or an
    OAuth1 access token holder could create an EC2 credential or an
    application credential using any roles the trustor, application
    credential creator, or access token authorizor had on the project,
    regardless of whether the creator had delegated only a limited subset of
    roles. This was because the trust_id attribute of the EC2 access blob
    was ignored, and no metadata for the application credential or access
    token was recorded either. This change ensures that the access
    delegation resource is recorded in the metadata of the EC2 credential
    when created and passed to the token provider when used for
    authentication so that the token provider can look up the correct roles
    for the request.

    Change-Id: I39d0d705839fbe31ac518ac9a82959e108cb7c1d
    Closes-bug: #1872733
    Closes-bug: #1872755
    Closes-bug: #1872735
    (cherry picked from commit 37e9907a176dad6843819b1bec4946c3aecc4548)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/725886
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=37e9907a176dad6843819b1bec4946c3aecc4548
Submitter: Zuul
Branch: master

commit 37e9907a176dad6843819b1bec4946c3aecc4548
Author: Colleen Murphy <email address hidden>
Date: Tue Apr 14 16:47:44 2020 -0700

    Fix security issues with EC2 credentials

    This change addresses several issues in the creation and use of EC2/S3
    credentials with keystone tokens.

    1. Disable altering credential owner attributes or metadata

    Without this patch, an authenticated user can create an EC2 credential
    for themself for a project they have a role on, then update the
    credential to target a user and project completely unrelated to them. In
    the worst case, this could be the admin user and a project the admin
    user has a role assignment on. A token granted for an altered credential
    like this would allow the user to masquerade as the victim user. This
    patch ensures that when updating a credential, the new form of the
    credential is one the acting user has access to: if the system admin
    user is changing the credential, the new user ID or project ID could be
    anything, but regular users may only change the credential to be one
    that they still own.

    Relatedly, when a user uses an application credential or a trust to
    create an EC2 credential, keystone automatically adds the trust ID or
    application credential ID as metadata in the EC2 access blob so that it
    knows how the token can be scoped when it is used. Without this patch, a
    user who has created a credential in this way can update the access blob
    to remove or alter this metadata and escalate their privileges to be
    fully authorized for the trustor's, application credential creator's, or
    OAuth1 access token authorizor's privileges on the project. This patch
    fixes the issue by simply disallowing updates to keystone-controlled
    metadata in the credential.

    2. Respect token roles when creating EC2 credentials

    Without this patch, a trustee, an application credential user, or an
    OAuth1 access token holder could create an EC2 credential or an
    application credential using any roles the trustor, application
    credential creator, or access token authorizor had on the project,
    regardless of whether the creator had delegated only a limited subset of
    roles. This was because the trust_id attribute of the EC2 access blob
    was ignored, and no metadata for the application credential or access
    token was recorded either. This change ensures that the access
    delegation resource is recorded in the metadata of the EC2 credential
    when created and passed to the token provider when used for
    authentication so that the token provider can look up the correct roles
    for the request.

    Change-Id: I39d0d705839fbe31ac518ac9a82959e108cb7c1d
    Closes-bug: #1872733
    Closes-bug: #1872755
    Closes-bug: #1872735

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/queens
Review: https://review.opendev.org/726435

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/725891
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=54590544fb7a2cd65e23fce8abcf77296352cd29
Submitter: Zuul
Branch: stable/train

commit 54590544fb7a2cd65e23fce8abcf77296352cd29
Author: Colleen Murphy <email address hidden>
Date: Tue Apr 14 16:47:44 2020 -0700

    Fix security issues with EC2 credentials

    This change addresses several issues in the creation and use of EC2/S3
    credentials with keystone tokens.

    1. Disable altering credential owner attributes or metadata

    Without this patch, an authenticated user can create an EC2 credential
    for themself for a project they have a role on, then update the
    credential to target a user and project completely unrelated to them. In
    the worst case, this could be the admin user and a project the admin
    user has a role assignment on. A token granted for an altered credential
    like this would allow the user to masquerade as the victim user. This
    patch ensures that when updating a credential, the new form of the
    credential is one the acting user has access to: if the system admin
    user is changing the credential, the new user ID or project ID could be
    anything, but regular users may only change the credential to be one
    that they still own.

    Relatedly, when a user uses an application credential or a trust to
    create an EC2 credential, keystone automatically adds the trust ID or
    application credential ID as metadata in the EC2 access blob so that it
    knows how the token can be scoped when it is used. Without this patch, a
    user who has created a credential in this way can update the access blob
    to remove or alter this metadata and escalate their privileges to be
    fully authorized for the trustor's, application credential creator's, or
    OAuth1 access token authorizor's privileges on the project. This patch
    fixes the issue by simply disallowing updates to keystone-controlled
    metadata in the credential.

    2. Respect token roles when creating EC2 credentials

    Without this patch, a trustee, an application credential user, or an
    OAuth1 access token holder could create an EC2 credential or an
    application credential using any roles the trustor, application
    credential creator, or access token authorizor had on the project,
    regardless of whether the creator had delegated only a limited subset of
    roles. This was because the trust_id attribute of the EC2 access blob
    was ignored, and no metadata for the application credential or access
    token was recorded either. This change ensures that the access
    delegation resource is recorded in the metadata of the EC2 credential
    when created and passed to the token provider when used for
    authentication so that the token provider can look up the correct roles
    for the request.

    Conflicts (six removal in e2d83ae9, pep8 fixes in e2d83ae9, test helper
    in 52da4d0e12):
          keystone/api/credentials.py
          keystone/tests/unit/test_v3_application_credential.py
          keystone/tests/unit/test_v3_credential.py

    Depends-on: htt...

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/725893
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=206392a40ce3da3d389e5e7ec721ada2737b84da
Submitter: Zuul
Branch: stable/stein

commit 206392a40ce3da3d389e5e7ec721ada2737b84da
Author: Colleen Murphy <email address hidden>
Date: Tue Apr 14 16:47:44 2020 -0700

    Fix security issues with EC2 credentials

    This change addresses several issues in the creation and use of EC2/S3
    credentials with keystone tokens.

    1. Disable altering credential owner attributes or metadata

    Without this patch, an authenticated user can create an EC2 credential
    for themself for a project they have a role on, then update the
    credential to target a user and project completely unrelated to them. In
    the worst case, this could be the admin user and a project the admin
    user has a role assignment on. A token granted for an altered credential
    like this would allow the user to masquerade as the victim user. This
    patch ensures that when updating a credential, the new form of the
    credential is one the acting user has access to: if the system admin
    user is changing the credential, the new user ID or project ID could be
    anything, but regular users may only change the credential to be one
    that they still own.

    Relatedly, when a user uses an application credential or a trust to
    create an EC2 credential, keystone automatically adds the trust ID or
    application credential ID as metadata in the EC2 access blob so that it
    knows how the token can be scoped when it is used. Without this patch, a
    user who has created a credential in this way can update the access blob
    to remove or alter this metadata and escalate their privileges to be
    fully authorized for the trustor's, application credential creator's, or
    OAuth1 access token authorizor's privileges on the project. This patch
    fixes the issue by simply disallowing updates to keystone-controlled
    metadata in the credential.

    2. Respect token roles when creating EC2 credentials

    Without this patch, a trustee, an application credential user, or an
    OAuth1 access token holder could create an EC2 credential or an
    application credential using any roles the trustor, application
    credential creator, or access token authorizor had on the project,
    regardless of whether the creator had delegated only a limited subset of
    roles. This was because the trust_id attribute of the EC2 access blob
    was ignored, and no metadata for the application credential or access
    token was recorded either. This change ensures that the access
    delegation resource is recorded in the metadata of the EC2 credential
    when created and passed to the token provider when used for
    authentication so that the token provider can look up the correct roles
    for the request.

    Conflicts (six removal in e2d83ae9, pep8 fixes in e2d83ae9):
          keystone/api/credentials.py
          keystone/tests/unit/test_v3_application_credential.py
          keystone/tests/unit/test_v3_credential.py

    Change-Id: I39d0d705839fbe31ac518ac9a82959e108...

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/725895
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=53d1ccb8a1bdbb5aa0efaacf9739b1a6f436e191
Submitter: Zuul
Branch: stable/rocky

commit 53d1ccb8a1bdbb5aa0efaacf9739b1a6f436e191
Author: Colleen Murphy <email address hidden>
Date: Tue Apr 14 16:47:44 2020 -0700

    Fix security issues with EC2 credentials

    This change addresses several issues in the creation and use of EC2/S3
    credentials with keystone tokens.

    1. Disable altering credential owner attributes or metadata

    Without this patch, an authenticated user can create an EC2 credential
    for themself for a project they have a role on, then update the
    credential to target a user and project completely unrelated to them. In
    the worst case, this could be the admin user and a project the admin
    user has a role assignment on. A token granted for an altered credential
    like this would allow the user to masquerade as the victim user. This
    patch ensures that when updating a credential, the new form of the
    credential is one the acting user has access to: if the system admin
    user is changing the credential, the new user ID or project ID could be
    anything, but regular users may only change the credential to be one
    that they still own.

    Relatedly, when a user uses an application credential or a trust to
    create an EC2 credential, keystone automatically adds the trust ID or
    application credential ID as metadata in the EC2 access blob so that it
    knows how the token can be scoped when it is used. Without this patch, a
    user who has created a credential in this way can update the access blob
    to remove or alter this metadata and escalate their privileges to be
    fully authorized for the trustor's, application credential creator's, or
    OAuth1 access token authorizor's privileges on the project. This patch
    fixes the issue by simply disallowing updates to keystone-controlled
    metadata in the credential.

    2. Respect token roles when creating EC2 credentials

    Without this patch, a trustee, an application credential user, or an
    OAuth1 access token holder could create an EC2 credential or an
    application credential using any roles the trustor, application
    credential creator, or access token authorizor had on the project,
    regardless of whether the creator had delegated only a limited subset of
    roles. This was because the trust_id attribute of the EC2 access blob
    was ignored, and no metadata for the application credential or access
    token was recorded either. This change ensures that the access
    delegation resource is recorded in the metadata of the EC2 credential
    when created and passed to the token provider when used for
    authentication so that the token provider can look up the correct roles
    for the request.

    Conflicts (six removal in e2d83ae9, pep8 fixes in e2d83ae9):
          keystone/api/credentials.py
          keystone/tests/unit/test_v3_application_credential.py
          keystone/tests/unit/test_v3_credential.py

    Conflicts due to flask reorg:
            keys...

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/726435
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=487c7276c7608fb11086b9875b0d7cc7cf594a5a
Submitter: Zuul
Branch: stable/queens

commit 487c7276c7608fb11086b9875b0d7cc7cf594a5a
Author: Colleen Murphy <email address hidden>
Date: Tue Apr 14 16:47:44 2020 -0700

    Fix security issues with EC2 credentials

    This change addresses several issues in the creation and use of EC2/S3
    credentials with keystone tokens.

    1. Disable altering credential owner attributes or metadata

    Without this patch, an authenticated user can create an EC2 credential
    for themself for a project they have a role on, then update the
    credential to target a user and project completely unrelated to them. In
    the worst case, this could be the admin user and a project the admin
    user has a role assignment on. A token granted for an altered credential
    like this would allow the user to masquerade as the victim user. This
    patch ensures that when updating a credential, the new form of the
    credential is one the acting user has access to: if the system admin
    user is changing the credential, the new user ID or project ID could be
    anything, but regular users may only change the credential to be one
    that they still own.

    Relatedly, when a user uses an application credential or a trust to
    create an EC2 credential, keystone automatically adds the trust ID or
    application credential ID as metadata in the EC2 access blob so that it
    knows how the token can be scoped when it is used. Without this patch, a
    user who has created a credential in this way can update the access blob
    to remove or alter this metadata and escalate their privileges to be
    fully authorized for the trustor's, application credential creator's, or
    OAuth1 access token authorizor's privileges on the project. This patch
    fixes the issue by simply disallowing updates to keystone-controlled
    metadata in the credential.

    2. Respect token roles when creating EC2 credentials

    Without this patch, a trustee, an application credential user, or an
    OAuth1 access token holder could create an EC2 credential or an
    application credential using any roles the trustor, application
    credential creator, or access token authorizor had on the project,
    regardless of whether the creator had delegated only a limited subset of
    roles. This was because the trust_id attribute of the EC2 access blob
    was ignored, and no metadata for the application credential or access
    token was recorded either. This change ensures that the access
    delegation resource is recorded in the metadata of the EC2 credential
    when created and passed to the token provider when used for
    authentication so that the token provider can look up the correct roles
    for the request.

    Conflicts (six removal in e2d83ae9, pep8 fixes in e2d83ae9):
          keystone/api/credentials.py
          keystone/tests/unit/test_v3_application_credential.py
          keystone/tests/unit/test_v3_credential.py

    Conflicts due to flask reorg:
            key...

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/726046
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=a405e4b71d7de31e81a01f07e02f189650eb66fe
Submitter: Zuul
Branch: stable/pike

commit a405e4b71d7de31e81a01f07e02f189650eb66fe
Author: Colleen Murphy <email address hidden>
Date: Tue Apr 14 16:47:44 2020 -0700

    Fix security issues with EC2 credentials

    This change addresses several issues in the creation and use of EC2/S3
    credentials with keystone tokens.

    1. Disable altering credential owner attributes or metadata

    Without this patch, an authenticated user can create an EC2 credential
    for themself for a project they have a role on, then update the
    credential to target a user and project completely unrelated to them. In
    the worst case, this could be the admin user and a project the admin
    user has a role assignment on. A token granted for an altered credential
    like this would allow the user to masquerade as the victim user. This
    patch ensures that when updating a credential, the new form of the
    credential is one the acting user has access to: if the system admin
    user is changing the credential, the new user ID or project ID could be
    anything, but regular users may only change the credential to be one
    that they still own.

    Relatedly, when a user uses an application credential or a trust to
    create an EC2 credential, keystone automatically adds the trust ID or
    application credential ID as metadata in the EC2 access blob so that it
    knows how the token can be scoped when it is used. Without this patch, a
    user who has created a credential in this way can update the access blob
    to remove or alter this metadata and escalate their privileges to be
    fully authorized for the trustor's, application credential creator's, or
    OAuth1 access token authorizor's privileges on the project. This patch
    fixes the issue by simply disallowing updates to keystone-controlled
    metadata in the credential.

    2. Respect token roles when creating EC2 credentials

    Without this patch, a trustee, an application credential user, or an
    OAuth1 access token holder could create an EC2 credential or an
    application credential using any roles the trustor, application
    credential creator, or access token authorizor had on the project,
    regardless of whether the creator had delegated only a limited subset of
    roles. This was because the trust_id attribute of the EC2 access blob
    was ignored, and no metadata for the application credential or access
    token was recorded either. This change ensures that the access
    delegation resource is recorded in the metadata of the EC2 credential
    when created and passed to the token provider when used for
    authentication so that the token provider can look up the correct roles
    for the request.

    Conflicts (six removal in e2d83ae9, pep8 fixes in e2d83ae9):
          keystone/api/credentials.py
          keystone/tests/unit/test_v3_application_credential.py
          keystone/tests/unit/test_v3_credential.py

    Conflicts due to flask reorg:
            keyst...

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/keystone pike-eol release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/keystone queens-eol release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/keystone rocky-eol release.