ec2 credential "trust_id" can be updated to null
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Fix Released
|
Medium
|
Colleen Murphy | ||
OpenStack Security Advisory |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
Similar to https:/
curl -X PATCH https:/
"credential": {
"blob": "{\"access\": \"ffe6fc21b47c4
}
}'
Note "null" in blob.
description: | updated |
Jeremy Stanley (fungi) wrote : | #1 |
description: | updated |
Changed in ossa: | |
status: | New → Incomplete |
Colleen Murphy (krinkle) wrote : | #2 |
- ec2.example Edit (4.9 KiB, text/plain)
I have verified that this is true, a credential created using a trust scope has the trust_id attribute in the blob and this can be PATCHed to set trust_id to null. However, I'm unclear on the consequences of this. No matter the content of the trust_id value of the blob, a token request using the EC2 credential does not have trust information in it, see attached example. Only the admin or owner can modify the credential. Can you explain with examples how this could be exploited?
kay (kay-diam) wrote : | #3 |
> a token request using the EC2 credential does not have trust information in it, see attached example.
This sounds insecure. What is the purpose of the "trust_id" attribute if it is not considered? Looks like it is another security flaw. I suppose a proper solution would be to add a scope field for all possible SUB auth methods, and consider this field when a new openstack token is generated during authorization:
* trust scope
* oauth1 scope
* application credential scope
* etc.
Thoughts?
Colleen Murphy (krinkle) wrote : | #4 |
I did some spelunking and it looks like the trust_id used to be used to add the correct roles to a token requested with an ec2 credential, and that functionality was mistakenly removed in https:/
Colleen Murphy (krinkle) wrote : | #5 |
Actually, the fixes will be different - this needs a change to the CRUD of the credential, 1872735 needs a change to the token validation, so not a duplicate. Will mark as medium severity since the main escalation path is 1872735.
Changed in keystone: | |
status: | New → Triaged |
importance: | Undecided → Medium |
Colleen Murphy (krinkle) wrote : | #6 |
- 0002-Prohibit-users-from-PATCHing-metadata-in-EC2-cred.patch Edit (9.2 KiB, text/plain)
Patch attached. This depends on the patch for https:/
kay (kay-diam) wrote : | #7 |
There is a typo in release notes:
- used by keystone to determine the scoped allowed
+ used by keystone to determine the scope allowed
Colleen Murphy (krinkle) wrote : | #8 |
- 0002-Prohibit-users-from-PATCHing-metadata-in-EC2-cred.patch Edit (9.2 KiB, text/plain)
Thanks for the review, new patch includes the typo fix.
Gage Hugo (gagehugo) wrote : | #9 |
Revised patch set looks good to me, thanks Colleen.
Changed in keystone: | |
milestone: | none → ussuri-rc1 |
Lance Bragstad (lbragstad) wrote : | #10 |
The patchset in comment #8 looks good.
Colleen Murphy (krinkle) wrote : | #11 |
Is a CVE being requested for this? How can we move this forward?
Changed in keystone: | |
status: | Triaged → In Progress |
milestone: | ussuri-rc1 → none |
assignee: | nobody → Colleen Murphy (krinkle) |
Gage Hugo (gagehugo) wrote : | #12 |
Since the exploitative method is described in https:/
[0] https:/
Jeremy Stanley (fungi) wrote : | #13 |
Sounds like we should at least delay disclosure of this until bug 1872735 is already public (we could plan to just switch them both at the same time).
Colleen Murphy (krinkle) wrote : | #14 |
Agreed on both counts, the exploit is covered by the other bug, but also this can't be safely disclosed separately from the other bug.
Colleen Murphy (krinkle) wrote : | #15 |
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.
Gage Hugo (gagehugo) wrote : | #16 |
The embargo for this bug has expired, will be making public 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) | #17 |
Fix proposed to branch: master
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix proposed to keystone (stable/ussuri) | #18 |
Fix proposed to branch: stable/ussuri
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix proposed to keystone (stable/train) | #19 |
Fix proposed to branch: stable/train
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix proposed to keystone (stable/stein) | #20 |
Fix proposed to branch: stable/stein
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix proposed to keystone (stable/rocky) | #21 |
Fix proposed to branch: stable/rocky
Review: https:/
Jeremy Stanley (fungi) wrote : | #22 |
I've set our advisory task to Won't Fix on this one, as no advisory is required with the fix for bug 1872735 effectively preventing the path to exploitation.
tags: | added: security |
information type: | Public Security → Public |
Changed in ossa: | |
status: | Incomplete → Won't Fix |
OpenStack Infra (hudson-openstack) wrote : Fix proposed to keystone (stable/pike) | #23 |
Fix proposed to branch: stable/pike
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix merged to keystone (stable/ussuri) | #24 |
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) | #25 |
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) | #26 |
Fix proposed to branch: stable/queens
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix merged to keystone (stable/train) | #27 |
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) | #28 |
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 |
Nick Tait (nickthetait) wrote : | #29 |
Too late to matter, but I also support Class D here.
OpenStack Infra (hudson-openstack) wrote : Fix merged to keystone (stable/rocky) | #30 |
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) | #31 |
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) | #32 |
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 | #33 |
This issue was fixed in the openstack/keystone pike-eol release.
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/keystone queens-eol | #34 |
This issue was fixed in the openstack/keystone queens-eol release.
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/keystone rocky-eol | #35 |
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.