[OSSA-2020-004] EC2 and/or credential endpoints are not protected from a scoped context (CVE-2020-12689)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Fix Released
|
High
|
Colleen Murphy | ||
OpenStack Security Advisory |
Fix Released
|
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/
I prepared a tool to auth against keyston using ec2 credentials: https:/
* auth against keystone using trust/oauth/
* issue ec2 credentials: "openstack ec2 credentials create"
* authenticate against keystone using ec2 credentials: "ec2auth --access 7522162ced8f4e3
You'll see that returned token contains all owner roles.
CVE References
Jeremy Stanley (fungi) wrote : | #1 |
description: | updated |
Changed in ossa: | |
status: | New → Incomplete |
Colleen Murphy (krinkle) wrote : | #2 |
- ec2.example.2 Edit (3.4 KiB, text/plain)
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 : | #3 |
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 : | #4 |
Thanks for the clarification, I've now reproduced this.
Changed in keystone: | |
status: | Invalid → Triaged |
importance: | Undecided → High |
Jeremy Stanley (fungi) wrote : | #5 |
This sounds like a class A report for a privilege escalation vulnerability:
https:/
Colleen Murphy (krinkle) wrote : | #6 |
- 0001-Respect-token-roles-when-creating-EC2-credentials.patch Edit (22.4 KiB, text/plain)
Attaching a fix for this. Running tempest and unit tests locally.
kay (kay-diam) wrote : | #7 |
> 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:/
Do I miss something?
Colleen Murphy (krinkle) wrote : | #8 |
> 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 : | #9 |
> Attaching a fix for this. Running tempest and unit tests locally.
Tempest and py37/pep8 tests passed for me locally.
kay (kay-diam) wrote : | #10 |
> 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:/
Colleen Murphy (krinkle) wrote : | #11 |
- 0001-Respect-token-roles-when-creating-EC2-credentials.patch Edit (22.7 KiB, text/plain)
Updated release note to include bug reference
Jeremy Stanley (fungi) wrote : | #12 |
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 : | #13 |
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 : | #14 |
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 : | #15 |
+2 on Colleen's patch in comment #11.
Colleen Murphy (krinkle) wrote : | #16 |
> 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 : | #17 |
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/
Colleen Murphy (krinkle) wrote : | #18 |
> 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:/
https:/
> 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 : | #19 |
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:/
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 : | #20 |
> > 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 : | #21 |
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/
Colleen Murphy (krinkle) wrote : | #22 |
> Verified this affects Rocky.
I was off by one in my head, I forgot that Rocky just went to EM. I interpret https:/
Jeremy Stanley (fungi) wrote : | #23 |
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 : | #24 |
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/
Jeremy Stanley (fungi) wrote : | #25 |
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 : | #26 |
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/
Colleen Murphy (krinkle) wrote : | #27 |
The impact description looks fine to me.
Changed in keystone: | |
status: | Triaged → In Progress |
assignee: | nobody → Colleen Murphy (krinkle) |
Jeremy Stanley (fungi) wrote : | #28 |
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 : | #29 |
Awaiting CVE, does the patch here apply cleanly to Stein/Train as well?
Colleen Murphy (krinkle) wrote : | #30 |
Colleen Murphy (krinkle) wrote : | #31 |
Colleen Murphy (krinkle) wrote : | #32 |
Gage Hugo (gagehugo) wrote : | #33 |
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 : | #34 |
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 : | #35 |
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 : | #36 |
May 6th works, we will still send out the embargo notification today.
Gage Hugo (gagehugo) wrote : | #37 |
Notification sent for this one.
Nick Tait (nickthetait) wrote : | #38 |
I also support Class A for this one. Description looks pretty good.
Colleen Murphy (krinkle) wrote : | #39 |
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:/
Nick Tait (nickthetait) wrote : | #40 |
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 : | #41 |
While not part of the VMT, I support simplifying the patches. Personally do not see any drawbacks to this option.
Colleen Murphy (krinkle) wrote : | #42 |
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 : | #43 |
Colleen Murphy (krinkle) wrote : | #44 |
Colleen Murphy (krinkle) wrote : | #45 |
Note that this patch only applies on top of the as-of-this-
Nick Tait (nickthetait) wrote : | #46 |
Description doesn't include 17. That needs fixing right?
Nick Tait (nickthetait) wrote : | #47 |
(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 : | #48 |
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 : | #49 |
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:/
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:
"identity:
"identity:
Thomas Goirand (thomas-goirand) wrote : | #50 |
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...
Thomas Goirand (thomas-goirand) wrote : | #51 |
- ec2_test_failure.txt Edit (19.0 KiB, text/plain)
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-
CVE_Check_
0002_Fix_
Please find attached failure dump.
Can you help fixing it?
Cheers,
Thomas Goirand
Colleen Murphy (krinkle) wrote : | #52 |
- bug 1873290 rocky patch Edit (5.5 KiB, text/plain)
Hi Thomas, as mentioned in comment 42 you will also need the fix for bug 1873290 in order for that unit test test_access_
Thomas Goirand (thomas-goirand) wrote : | #53 |
With this last patch that was missing, all builds fine, thanks!
Pushing this to the Debian security team.
Gage Hugo (gagehugo) wrote : | #54 |
Hi Thomas,
The disclosure date is tomorrow at 1500 UTC, would you need this extended?
Thomas Goirand (thomas-goirand) wrote : | #55 |
Oh, I thought it was today. Tomorrow is fine for me then, this gives me plenty of time for testing!
Jeremy Stanley (fungi) wrote : | #56 |
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.
Thomas Goirand (thomas-goirand) wrote : | #57 |
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 : | #58 |
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 |
OpenStack Infra (hudson-openstack) wrote : Fix proposed to keystone (master) | #59 |
Fix proposed to branch: master
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix proposed to keystone (stable/ussuri) | #60 |
Fix proposed to branch: stable/ussuri
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix proposed to keystone (stable/train) | #61 |
Fix proposed to branch: stable/train
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix proposed to keystone (stable/stein) | #62 |
Fix proposed to branch: stable/stein
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix proposed to keystone (stable/rocky) | #63 |
Fix proposed to branch: stable/rocky
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix merged to ossa (master) | #64 |
Reviewed: https:/
Committed: https:/
Submitter: Zuul
Branch: master
commit 2548f46b0aff357
Author: Gage Hugo <email address hidden>
Date: Wed May 6 10:57:15 2020 -0500
Add OSSA-2020-004 (CVEs Pending)
Change-Id: Ide28e91b184eda
Closes-Bug: #1872735
Closes-Bug: #1872733
Changed in ossa: | |
status: | In Progress → Fix Released |
OpenStack Infra (hudson-openstack) wrote : Fix proposed to keystone (stable/pike) | #65 |
Fix proposed to branch: stable/pike
Review: https:/
Nick Tait (nickthetait) wrote : Re: EC2 and/or credential endpoints are not protected from a scoped context | #66 |
Any news on CVE assignment? This seems longer than usual.
Gage Hugo (gagehugo) wrote : | #67 |
I got a reply last night, updates will go out this afternoon.
Jeremy Stanley (fungi) wrote : | #68 |
Our best guess is that MITRE is recently backlogged (understaffed/
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) |
OpenStack Infra (hudson-openstack) wrote : Fix merged to keystone (stable/ussuri) | #69 |
Reviewed: https:/
Committed: https:/
Submitter: Zuul
Branch: stable/ussuri
commit 2f2736ebb267c75
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: I39d0d705839fbe
Closes-bug: #1872733
Closes-bug: #1872755
Closes-bug: #1872735
(cherry picked from commit 37e9907a176dad6
tags: | added: in-stable-ussuri |
OpenStack Infra (hudson-openstack) wrote : Fix merged to keystone (master) | #70 |
Reviewed: https:/
Committed: https:/
Submitter: Zuul
Branch: master
commit 37e9907a176dad6
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: I39d0d705839fbe
Closes-bug: #1872733
Closes-bug: #1872755
Closes-bug: #1872735
Changed in keystone: | |
status: | In Progress → Fix Released |
OpenStack Infra (hudson-openstack) wrote : Fix proposed to keystone (stable/queens) | #71 |
Fix proposed to branch: stable/queens
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix merged to keystone (stable/train) | #72 |
Reviewed: https:/
Committed: https:/
Submitter: Zuul
Branch: stable/train
commit 54590544fb7a2cd
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):
Depends-on: htt...
tags: | added: in-stable-train |
OpenStack Infra (hudson-openstack) wrote : Fix merged to keystone (stable/stein) | #73 |
Reviewed: https:/
Committed: https:/
Submitter: Zuul
Branch: stable/stein
commit 206392a40ce3da3
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):
Change-Id: I39d0d705839fbe
tags: | added: in-stable-stein |
OpenStack Infra (hudson-openstack) wrote : Fix merged to keystone (stable/rocky) | #74 |
Reviewed: https:/
Committed: https:/
Submitter: Zuul
Branch: stable/rocky
commit 53d1ccb8a1bdbb5
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):
Conflicts due to flask reorg:
keys...
tags: | added: in-stable-rocky |
OpenStack Infra (hudson-openstack) wrote : Fix merged to keystone (stable/queens) | #75 |
Reviewed: https:/
Committed: https:/
Submitter: Zuul
Branch: stable/queens
commit 487c7276c7608fb
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):
Conflicts due to flask reorg:
key...
tags: | added: in-stable-queens |
OpenStack Infra (hudson-openstack) wrote : Fix merged to keystone (stable/pike) | #76 |
Reviewed: https:/
Committed: https:/
Submitter: Zuul
Branch: stable/pike
commit a405e4b71d7de31
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):
Conflicts due to flask reorg:
tags: | added: in-stable-pike |
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/keystone pike-eol | #77 |
This issue was fixed in the openstack/keystone pike-eol release.
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/keystone queens-eol | #78 |
This issue was fixed in the openstack/keystone queens-eol release.
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/keystone rocky-eol | #79 |
This issue was fixed in the openstack/keystone rocky-eol release.
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.