[OSSA-2020-004] EC2 and/or credential endpoints are not protected from a scoped context (CVE-2020-12689)

Bug #1872735 reported by kay on 2020-04-14
266
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
High
Colleen Murphy
OpenStack Security Advisory
Undecided
Unassigned

Bug Description

Being authorized within a limited scope context, i.e. trust / oauth / application credential with a limited role, e.g. "monitoring_viewer" or "viewer", it is still possible to create EC2 credentials. User can auth against Keystone using EC2 credentials and obtain all project roles
 of a trust/oauth/application_credential owner.

I prepared a tool to auth against keyston using ec2 credentials: https://github.com/kayrus/ec2auth

* auth against keystone using trust/oauth/application_credential credentials
* issue ec2 credentials: "openstack ec2 credentials create"
* authenticate against keystone using ec2 credentials: "ec2auth --access 7522162ced8f4e3eb9502168ef199584 --secret c558d9401a6943bbbb77a83ce910e5a5 --debug"

You'll see that returned token contains all owner roles.

CVE References

Jeremy Stanley (fungi) wrote :

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.

description: updated
Changed in ossa:
status: New → Incomplete
Colleen Murphy (krinkle) wrote :

Attached is what I get when I use your tool to authenticate with an ec2 credential for a user who only has the "reader" role on the "demo" project. The token only contains the "reader" role, which is expected. Any project-scoped request the user makes will be limited by that role.

Changed in keystone:
status: New → Invalid
kay (kay-diam) wrote :

Hi Colleen. Sorry for not being clear enough. I was talking about creating EC2 credentials under "trust / oauth / application credential". For instance, when your base user has "admin" and "viewer" roles, you create "application credential" with a "viewer" and expect that "application credential" won't be able to escalate privileges to "admin".

However being authed using "application credential" with a "viewer" role allows to create EC2 credentials, which are associated with a parent user. Therefore "application credential" with a "viewer" role can successfully escalate privileges to "admin".

I uploaded more detailed JSON logs for convenience. Note that I created "application credential" with a limited "monitoring_viewer" role, then created "ec2 credentials" within "application credential" scope, and escalated privileges to parent user roles.

Colleen Murphy (krinkle) wrote :

Thanks for the clarification, I've now reproduced this.

Changed in keystone:
status: Invalid → Triaged
importance: Undecided → High
Jeremy Stanley (fungi) wrote :

This sounds like a class A report for a privilege escalation vulnerability:

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

Colleen Murphy (krinkle) wrote :

Attaching a fix for this. Running tempest and unit tests locally.

kay (kay-diam) wrote :

> OAUTH1 tokens already always contain all of the roles the authorizing user has on the requested project, ignoring the authorized roles that are stored with the access token during the authorization request.

Hi Colleen, thanks for a fix. I read the "https://docs.openstack.org/api-ref/identity/v3-ext/?expanded=authorize-request-token-detail#authorize-request-token" and I'm confused, why does the request contain roles list?

https://github.com/openstack/keystone/blob/7bb6314e40d6947294260324e84a58de191f8609/keystone/api/os_oauth1.py#L287

Do I miss something?

Colleen Murphy (krinkle) wrote :

> I'm confused, why does the request contain roles list?

I find this confusing too. Let me know if you see the same behavior. I don't think it's the intended behavior but as far as I can tell it's either always been that way or has for a long time, and wasn't discovered because it used to be rare to have more than one role assignment on a project.

I think it's fixable but the patch for this bug was already getting dense. I think opening a second (public?) bug might be worthwhile.

Colleen Murphy (krinkle) wrote :

> Attaching a fix for this. Running tempest and unit tests locally.

Tempest and py37/pep8 tests passed for me locally.

kay (kay-diam) wrote :

> I think opening a second (public?) bug might be worthwhile.

To be on the safe side, I'd open a private issue for this, because "openstack request token authorize" requires a role definition and "OAuth1 trustor" user expects that oauth1 token will be limited to this role, but it this role is ignored by Keystone: https://bugs.launchpad.net/keystone/+bug/1873290

Colleen Murphy (krinkle) wrote :

Updated release note to include bug reference

Jeremy Stanley (fungi) wrote :

Given the interrelationship, should we try to cover this and bug 1873290 in the same advisory, or write them up and disclose them independently when the time comes?

Gage Hugo (gagehugo) wrote :

Colleen's patch looks fine, would like another pair of eyes on it as well as it touches a bit more logic here.

Kristi Nikolla (knikolla) wrote :

Colleen's patch at #11 looks good and the test correctly covers the issue. The release note also accurately describes the problem and solution.

Lance Bragstad (lbragstad) wrote :

+2 on Colleen's patch in comment #11.

Colleen Murphy (krinkle) wrote :

> Given the interrelationship, should we try to cover this and bug 1873290 in the same advisory, or write them up and disclose them independently when the time comes?

Although they are separate problems, the solution to bug 1873290 is closely related to the solution to this one so I think it's not possible to safely disclose them separately.

Gage Hugo (gagehugo) wrote :

Below is a rough draft for an impact description for this bug, please review it for any changes.

I assumed this will not get fixed before ussuri release as we will need this impact before obtaining a CVE.

Also @kay, if there is another name/alias you wish to go by, please feel free to correct me.

Title: EC2 and/or credential endpoints are not protected from a scoped context
Reporter: kay (kay-diam)
Products: Keystone
Affects: ==15.0.0, ==16.0.0, ==17.0.0

Description:
kay (kay-diam) reported a vulnerability in Keystone's EC2 credentials API. Any user authenticated within a limited scope (trust/oauth/application credential) can create an EC2 credential with an escalated permission, such as obtaining "admin" while the user is on a limited "viewer" role.

Colleen Murphy (krinkle) wrote :

> Affects: ==15.0.0, ==16.0.0, ==17.0.0

I think this affects Rocky too, which is 14.0.0. Will verify shortly.
https://opendev.org/openstack/keystone/src/branch/stable/rocky/keystone/contrib/ec2/controllers.py#L148-L150
https://opendev.org/openstack/keystone/src/branch/stable/rocky/keystone/contrib/ec2/controllers.py#L296-L298

> Any user authenticated within a limited scope ... can create an EC2 credential with an escalated permission, such as obtaining "admin" while the user is on a limited "viewer" role.

This look okay to me, though I think it overestimates the problem slightly. The user who is exploiting this can only assume the role assignments that the delegator currently has on the project, which might not necessarily be as bad as admin. But if the impact description is meant to illustrate the worst-case scenario then this looks fine to me.

Jeremy Stanley (fungi) wrote :

Examples in advisories will typically illustrate worst-case scenarios, but we use terms like "can," "could," "may," or "might" so as to avoid writing in absolutes and make it apparent that the severity of the impact depends greatly on situational variables.

As for whether this can be disclosed soon enough to make it into Ussuri, final release candidates aren't due until May 8. If we took the day before as the proposed disclosure date (which would admittedly be cutting it close), then we would need a suitable impact description and working backports no later than May 4. If we had those any time between now and April 25, we could set a disclosure date of April 28 (too late for RC1 so would need to be committed to both master and stable/ussuri branches, but still well in time for the release). Timeframes for coordinated disclosure are calculated per the rules outlined here: https://security.openstack.org/vmt-process.html#embargoed-disclosure

Also, the reporter detail in parentheses would typically be Kay's employer or other affiliated organization they wanted to credit along with their name.

Colleen Murphy (krinkle) wrote :

> > Affects: ==15.0.0, ==16.0.0, ==17.0.0

> I think this affects Rocky too, which is 14.0.0. Will verify shortly.

Verified this affects Rocky.

Gage Hugo (gagehugo) wrote :

Updated, please review:

Title: EC2 and/or credential endpoints are not protected from a scoped context
Reporter: kay
Products: Keystone
Affects: >=14.0.0 <=14.2.0, ==15.0.0, ==16.0.0

Description:
kay reported a vulnerability in Keystone's EC2 credentials API. Any user authenticated within a limited scope (trust/oauth/application credential) can create an EC2 credential with an escalated permission, such as obtaining "admin" while the user is on a limited "viewer" role.

Colleen Murphy (krinkle) wrote :

> Verified this affects Rocky.

I was off by one in my head, I forgot that Rocky just went to EM. I interpret https://security.openstack.org/vmt-process.html#supported-versions to mean we don't need to support fixes for Rocky? (a lot of the controller code changed between Rocky and Stein so the backport is a pain)

Jeremy Stanley (fungi) wrote :

Yes, if Rocky has entered extended maintenance now for Keystone, there will be no new Rocky stable point release which includes the fix (even if the stable/rocky branch gets a backport of it under extended maintenance). We usually try to refer to ranges with inequalities excluding the next highest possible version number, which for Stein would be 15.0.1. When there's only a singular version in the range, like with 16.0.0 for Train, an equivalency is acceptable. There should be no need to mention 17.0.0 unless the fix does not get backported into stable/ussuri prior to Ussuri release day. As such, an accurate impact would include...

Affects: <15.0.1, ==16.0.0

Gage Hugo (gagehugo) wrote :

Updated, please review:

Title: EC2 and/or credential endpoints are not protected from a scoped context
Reporter: kay
Products: Keystone
Affects: <15.0.1, ==16.0.0

Description:
kay reported a vulnerability in Keystone's EC2 credentials API. Any user authenticated within a limited scope (trust/oauth/application credential) can create an EC2 credential with an escalated permission, such as obtaining "admin" while the user is on a limited "viewer" role.

Jeremy Stanley (fungi) wrote :

Also, the "and/or" in the title should probably just be "and" as that's more inclusive and less likely to lead to confusion if someone has both.

Gage Hugo (gagehugo) wrote :

Updated, please review:

Title: EC2 and credential endpoints are not protected from a scoped context
Reporter: kay
Products: Keystone
Affects: <15.0.1, ==16.0.0

Description:
kay reported a vulnerability in Keystone's EC2 credentials API. Any user authenticated within a limited scope (trust/oauth/application credential) can create an EC2 credential with an escalated permission, such as obtaining "admin" while the user is on a limited "viewer" role.

Colleen Murphy (krinkle) wrote :

The impact description looks fine to me.

Changed in keystone:
status: Triaged → In Progress
assignee: nobody → Colleen Murphy (krinkle)
Jeremy Stanley (fungi) wrote :

I agree, Gage's impact description in comment #26 looks ready for a CVE assignment request.

Separately, it seems we've reached some consensus that we should switch bug 1872755 to public at the same time this report is officially disclosed.

Gage Hugo (gagehugo) wrote :

Awaiting CVE, does the patch here apply cleanly to Stein/Train as well?

Colleen Murphy (krinkle) wrote :

The patch does not apply cleanly. Attaching the modified backports for stein and train.

Colleen Murphy (krinkle) wrote :
Colleen Murphy (krinkle) wrote :

Fixed unit test for stein patch

Gage Hugo (gagehugo) wrote :

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

May 5 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) wrote :

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

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

Gage Hugo (gagehugo) wrote :

Notification sent for this one.

Nick Tait (nickthetait) wrote :

I also support Class A for this one. Description looks pretty good.

Colleen Murphy (krinkle) wrote :

I'd like to propose squashing the patches for this and the other currently-private EC2 bugs reported by kay into one patch, with the fix for the OAuth1 bug 1873290 kept as its own patch that will only affect the token model code and not the EC2 credential code. This cuts the number of patches needed from 4 per branch down to 2, so with 4 branches the total number is cut from 16 to 8. This eliminates the merge conflicts, will make it easier for stakeholders to patch their packages and deployments and will make the public review and backporting process in gerrit much smoother. I've reworked the patches for master in my development environment and am currently validating them, and if the VMT is okay with this approach I will do the same for ussuri, train, and stein and attach them to the relevant bugs.

If, on the other hand, it is too late to do this reorganization since the embargo notification has already been sent, I will instead just update the patches to resolve the merge conflict with the now-landed https://review.opendev.org/724124.

Nick Tait (nickthetait) wrote :

Simplifying the number of patches is highly desirable (but I'm not a VMT member). If a notified downstream fails to request access and pay attention to developments, that is on them.

Nick Tait (nickthetait) wrote :

While not part of the VMT, I support simplifying the patches. Personally do not see any drawbacks to this option.

Colleen Murphy (krinkle) wrote :

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. Attaching patches for master, ussuri, train, and stein.

Colleen Murphy (krinkle) wrote :
Colleen Murphy (krinkle) wrote :
Colleen Murphy (krinkle) wrote :

Note that this patch only applies on top of the as-of-this-writing-unmerged https://review.opendev.org/725069

Nick Tait (nickthetait) wrote :

Description doesn't include 17. That needs fixing right?

Nick Tait (nickthetait) wrote :

(I was trying to talk about the affects field of description but didn't mention that)
Corrected version should read
Affects: <15.0.1, ==16.0.0, ==17.0.0

Gage Hugo (gagehugo) wrote :

The goal is to get this merged into Ussuri before the release is cut, so any releases after 16.0.0 should not be vulnerable.

Colleen Murphy (krinkle) wrote :

I'm attaching a patch for rocky even though it has reached EM to help distros that need to support older releases. This patch must be applied on top of this public patch: https://review.opendev.org/725385

To mitigate this bug for older branches, I recommend disabling the use of ec2 and s3 tokens as authentication mechanisms by removing ec2_extension, ec2_extension_v3, and s3_extension from the paste pipelines in keystone-paste.ini. Note that this will not work for rocky - even though keystone includes an example keystone-paste.ini file, it is not respected in the keystone service as this release was a transitional release away from the paste middleware implementation.

An alternative mitigation strategy is to disable the ability to create and modify credentials by restricting them with policies. For example, you can use the following rules in your policy.json:

"identity:create_credential": "!"
"identity:update_credential": "!"
"identity:ec2_create_credential": "!"

Hi,

I found that less than 24 hours is a very short timeframe to get things organized:
- patch the distro
- test the patch
- send to the security team
- wait for approval
- upload
- wait for security team ACK of the upload

All of this in a few hours of time (since I got the pre-OSSA yesterday before sleep time) is really too short. I understand the urgency to fix this before the release is out, though we have until Friday for this, so maybe waiting until tomorrow was enough, no?

I'm working on this, hopefully I can catch up before the 1500 UTC deadline...

Hi Colleen,

I'm getting a unit test failure when building Keystone for Debian Buster (that's Rocky) with the added patches on top of 14.2.0:

0001-Add-cadf-auditing-to-credentials.patch
CVE_Check_timestamp_of_signed_EC2_token_request.patch
0002_Fix_security_issues_with_EC2_credentials.patch

Please find attached failure dump.

Can you help fixing it?

Cheers,

Thomas Goirand

Colleen Murphy (krinkle) wrote :

Hi Thomas, as mentioned in comment 42 you will also need the fix for bug 1873290 in order for that unit test test_access_token_ec2_credential to pass. I will attach the patch for rocky here for your convenience.

With this last patch that was missing, all builds fine, thanks!

Pushing this to the Debian security team.

Gage Hugo (gagehugo) wrote :

Hi Thomas,

The disclosure date is tomorrow at 1500 UTC, would you need this extended?

Oh, I thought it was today. Tomorrow is fine for me then, this gives me plenty of time for testing!

Jeremy Stanley (fungi) wrote :

Yes, and sorry about the tight disclosure timeline. OpenStack's VMT process recommends 3-5 "business days" between downstream stakeholder notification and publication, but with final RCs for Ussuri due on Thursday we wanted to avoid releasing with known vulnerabilities which have fixes ready. As it is, we chose Wednesday instead of Tuesday because we realized last weekend was a major holiday for much of the World.

Hi Jeremy,

It's all on me. I thought I had only about 16 hours to do my tests, but there's 24 hours more than what I thought, which should hopefully be enough.

Gage Hugo (gagehugo) wrote :

The embargo for this bug will now be lifted and fixes will be available in gerrit here shortly.

description: updated
information type: Private Security → Public Security

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

Changed in ossa:
status: In Progress → Fix Released

Any news on CVE assignment? This seems longer than usual.

Gage Hugo (gagehugo) wrote :

I got a reply last night, updates will go out this afternoon.

Jeremy Stanley (fungi) wrote :

Our best guess is that MITRE is recently backlogged (understaffed/overworked?), and our publications to the oss-security ML yesterday prompted them to complete our requested assignments.

Gage Hugo (gagehugo) on 2020-05-07
summary: - EC2 and/or credential endpoints are not protected from a scoped context
+ [OSSA-2020-004] EC2 and/or credential endpoints are not protected from a
+ scoped context (CVE-2020-12689)

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)

tags: added: in-stable-ussuri

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

Changed in keystone:
status: In Progress → Fix Released
Download full text (3.4 KiB)

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

Read more...

tags: added: in-stable-train
Download full text (3.4 KiB)

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

Read more...

tags: added: in-stable-stein
Download full text (3.9 KiB)

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

Read more...

tags: added: in-stable-rocky
Download full text (4.3 KiB)

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

Read more...

tags: added: in-stable-queens
Download full text (4.2 KiB)

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

Read more...

tags: added: in-stable-pike
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers