[OSSA-2020-005] OAuth1 request token authorize silently ignores roles parameter (CVE-2020-12690)

Bug #1873290 reported by kay on 2020-04-16
264
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Medium
Colleen Murphy
OpenStack Security Advisory
Undecided
Unassigned

Bug Description

Sorry for using "trustor" and "trustee" terms in OAuth1 context, but these terms clearly describe users positions.

OpenStack CLI explicitly requires an OAuth1 "trustor" to specify a role for an OAuth1 Access Token:

$ openstack request token authorize
usage: openstack request token authorize [-h]
                                         [-f {json,shell,table,value,yaml}]
                                         [-c COLUMN] [--noindent]
                                         [--prefix PREFIX]
                                         [--max-width <integer>] [--fit-width]
                                         [--print-empty] --request-key
                                         <request-key> --role <role>
openstack request token authorize: error: the following arguments are required: --request-key, --role

However a specified role is silently ignored and OAuth1 token gets all OAuth1 "trustor" roles.

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

As an OAuth1 "trustor" I expect the "trustee" to have only accepted roles.

CVE References

kay (kay-diam) on 2020-04-16
description: updated
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 :

Attaching patch which also addresses the remainder of https://bugs.launchpad.net/keystone/+bug/1872735

Changed in keystone:
status: New → In Progress
importance: Undecided → Medium
assignee: nobody → Colleen Murphy (krinkle)
Colleen Murphy (krinkle) wrote :

Corrected the patch to account for bug 1872755

Colleen Murphy (krinkle) on 2020-04-21
Changed in keystone:
milestone: none → ussuri-rc1
Gage Hugo (gagehugo) wrote :

The included ps looks ok to me.

Lance Bragstad (lbragstad) wrote :

+2 from me on the proposed patch in comment #3.

Colleen Murphy (krinkle) wrote :

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

Changed in keystone:
milestone: ussuri-rc1 → none
Jeremy Stanley (fungi) wrote :

If I'm reading the report correctly, this sounds like it could represent an unintended privilege escalation, though I'll defer to those more familiar with Keystone as to whether it's exploitable in practice. If it is, then it sounds like a class A report, in which case we'll want to draft an impact description, request a CVE and propose a disclosure timeline once stable branch backports are confirmed viable.

Gage Hugo (gagehugo) wrote :

Yes, it's looking like unintended privilege escalation, so Class A in this case.

Gage Hugo (gagehugo) wrote :

First impact draft below, please review:

Title: OAuth1 request token authorize silently ignores roles parameter
Reporter: kay
Products: Keystone
Affects: <15.0.1, ==16.0.0

Description:
kay reported a vulnerability in Keystone's OAuth1 Token API. Previously the list of roles provided for an OAuth1 access token were ignored, so when an access token was created, it would contain every role assignment the creator had for the project. This results in an OAuth1 access token having more role assignments than the creator intended, possibly giving unintended escalated access.

Colleen Murphy (krinkle) wrote :

> so when an access token was created, it would contain every role assignment the creator had for the project. This results in an OAuth1 access token having more role assignments than the creator intended

Technically it's not the OAuth1 access token that contains too many roles but the keystone token. I'm attaching a new version of the patch which updates the release notes to clarify that point.

Gage Hugo (gagehugo) wrote :

Updated to add the distinction between the two tokens:

Title: OAuth1 request token authorize silently ignores roles parameter
Reporter: kay
Products: Keystone
Affects: <15.0.1, ==16.0.0

Description:
kay reported a vulnerability in Keystone's OAuth1 Token API. Previously the list of roles provided for an OAuth1 access token were ignored, so when an access token was used to request a keystone token, the keystone token would contain every role assignment the creator had for the project. This results in the provided keystone token having more role assignments than the creator intended, possibly giving unintended escalated access.

Colleen Murphy (krinkle) wrote :

lgtm

Jeremy Stanley (fungi) wrote :

Gage's impact description in comment #11 seems fine to me, we should proceed with a CVE request for this.

The fact that exploitation is limited to trusted users and needs someone with the desired permissions to at least issue an OAuth1 token, the risk of continuing discussion in public seems limited. How does everyone feel about switching to a public workflow for this report?

Colleen Murphy (krinkle) wrote :

Given the relationship with the more serious bug 1872735 and the fact that the proposed patch references and applies on top of the fix for that bug, I do not think it's safe make this bug public.

Jeremy Stanley (fungi) wrote :

Thanks Colleen, in that case I suppose they should be disclosed at the same time, either though coincident advisories or by switching this to a public workflow once fixes for 1872735 are published.

Gage Hugo (gagehugo) wrote :

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

Colleen Murphy (krinkle) wrote :

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

Colleen Murphy (krinkle) wrote :
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 :

Sounds reasonable, we will still send out the notification today.

Gage Hugo (gagehugo) wrote :

notification sent for this one.

Mohammed Naser (mnaser) wrote :

Hi everyone,

I think the patch is not applying cleanly:

============
➜ keystone git:(master) (☸ N/A) pwd
/Users/mnaser/src/opendev.org/openstack/keystone
➜ keystone git:(master) (☸ N/A) git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean
➜ keystone git:(master) (☸ N/A) patch -p1 < ~/Downloads/0003-Ensure-OAuth1-authorized-roles-are-respected.patch-master
patching file keystone/api/_shared/EC2_S3_Resource.py
Hunk #1 FAILED at 84.
Hunk #2 FAILED at 104.
Hunk #3 FAILED at 122.
Hunk #4 FAILED at 148.
4 out of 4 hunks FAILED -- saving rejects to file keystone/api/_shared/EC2_S3_Resource.py.rej
patching file keystone/api/credentials.py
Hunk #1 FAILED at 74.
Hunk #2 succeeded at 85 with fuzz 2 (offset -7 lines).
Hunk #3 FAILED at 152.
Hunk #4 FAILED at 168.
3 out of 4 hunks FAILED -- saving rejects to file keystone/api/credentials.py.rej
patching file keystone/models/token_model.py
patching file keystone/tests/unit/test_v3_credential.py
Hunk #2 succeeded at 260 with fuzz 2 (offset -83 lines).
Hunk #3 succeeded at 502 (offset -172 lines).
patching file keystone/tests/unit/test_v3_oauth1.py
patching file releasenotes/notes/bug-1873290-ff7f8e4cee15b75a.yaml
➜ keystone git:(master) ✗ (☸ N/A)
============

Some parts (like in credentials.py reference code that doesn't seem to exist anywhere visible to me).

Colleen Murphy (krinkle) wrote :

Hi Mohammed, the patch here is the third in a series, the other patches can be found in bug 1872735 (1st) and bug 1872755 (2nd) (noted as related bugs in the commit message of this patch). The bugs all affect primarily keystone/api/credentials.py and keystone/api/_shared/EC2_S3_Resource.py so it is unfortunately difficult to tease them into independent patches.

Mohammed Naser (mnaser) wrote :

Gotcha, so the patches are indeed stacked. Sorry for missing that.

Colleen Murphy (krinkle) wrote :

Actually, in addition to that they also conflict with another related patch that was just merged in master https://review.opendev.org/724124. Working on an updated stack now.

Nick Tait (nickthetait) wrote :

I support Class A for this bug too. As far as the description, I don't have many specific improvements to suggest except the last sentence might be improved as "This results in a malicious user gaining more role assignments than the creator intended, such as admin access." Here are the parts that confuse me:

"Previously" was this recent or ancient news? does it matter?
"ignored" by what component(s)?
Difficult to distinguish between the two (access vs keystone) tokens. Can this be simplified somehow?
"the creator" does this refer to the user, an administrator, keystone, or something else?

Colleen Murphy (krinkle) wrote :

I've reworked the patch for this bug to be independently appliable. Attaching patches for master, ussuri, train, and stein.

Colleen Murphy (krinkle) wrote :
Colleen Murphy (krinkle) wrote :
Colleen Murphy (krinkle) wrote :
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.

To mitigate this bug for older branches, I recommend disabling 'oauth1' as an authentication method by removing it from the comma-separated list in the [auth]/methods config option in keystone.conf. Alternatively, although the default policy rules for these actions are already very restrictive, you can further restrict them by disabling them completely with policy rules such as:

"identity:create_consumer": "!"
"identity:update_consumer": "!"
"identity:authorize_request_token": "!"

Gage Hugo (gagehugo) wrote :

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

information type: Private Security → Public Security
description: updated

Reviewed: https://review.opendev.org/725917
Committed: https://git.openstack.org/cgit/openstack/ossa/commit/?id=3696964abeeef77b725d452b1cda8c79568d5ad0
Submitter: Zuul
Branch: master

commit 3696964abeeef77b725d452b1cda8c79568d5ad0
Author: Gage Hugo <email address hidden>
Date: Wed May 6 11:06:58 2020 -0500

    Add OSSA-2020-005 (CVE Pending)

    Change-Id: I6b422cc4491d2c785565716ee4d07ca58efcdb0a
    Closes-Bug: #1873290

Changed in ossa:
status: In Progress → Fix Released

Reviewed: https://review.opendev.org/725885
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=6c73690f779a42a5c62914b6bc37f0ac2f41a3e3
Submitter: Zuul
Branch: master

commit 6c73690f779a42a5c62914b6bc37f0ac2f41a3e3
Author: Colleen Murphy <email address hidden>
Date: Thu Apr 16 20:35:46 2020 -0700

    Ensure OAuth1 authorized roles are respected

    Without this patch, when an OAuth1 request token is authorized with a
    limited set of roles, the roles for the access token are ignored when
    the user uses it to request a keystone token. This means that user of an
    access token can use it to escallate their role assignments beyond what
    was authorized by the creator. This patch fixes the issue by ensuring
    the token model accounts for an OAuth1-scoped token and correctly
    populating the roles for it.

    Change-Id: I02f9836fbd4d7e629653977fc341476cfd89859e
    Closes-bug: #1873290

Changed in keystone:
status: In Progress → Fix Released
Gage Hugo (gagehugo) on 2020-05-07
summary: - OAuth1 request token authorize silently ignores roles parameter
+ [OSSA-2020-005] OAuth1 request token authorize silently ignores roles
+ parameter (CVE-2020-12690)

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

commit ba89d27793c2d3a26ad95642660fa9bd820ed3be
Author: Colleen Murphy <email address hidden>
Date: Thu Apr 16 20:35:46 2020 -0700

    Ensure OAuth1 authorized roles are respected

    Without this patch, when an OAuth1 request token is authorized with a
    limited set of roles, the roles for the access token are ignored when
    the user uses it to request a keystone token. This means that user of an
    access token can use it to escallate their role assignments beyond what
    was authorized by the creator. This patch fixes the issue by ensuring
    the token model accounts for an OAuth1-scoped token and correctly
    populating the roles for it.

    Change-Id: I02f9836fbd4d7e629653977fc341476cfd89859e
    Closes-bug: #1873290
    (cherry picked from commit 6c73690f779a42a5c62914b6bc37f0ac2f41a3e3)

tags: added: in-stable-ussuri

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

commit fe4d48d554a1a8ce1806de2831218907328dc89a
Author: Colleen Murphy <email address hidden>
Date: Thu Apr 16 20:35:46 2020 -0700

    Ensure OAuth1 authorized roles are respected

    Without this patch, when an OAuth1 request token is authorized with a
    limited set of roles, the roles for the access token are ignored when
    the user uses it to request a keystone token. This means that user of an
    access token can use it to escallate their role assignments beyond what
    was authorized by the creator. This patch fixes the issue by ensuring
    the token model accounts for an OAuth1-scoped token and correctly
    populating the roles for it.

    Change-Id: I02f9836fbd4d7e629653977fc341476cfd89859e
    Closes-bug: #1873290
    (cherry picked from commit 6c73690f779a42a5c62914b6bc37f0ac2f41a3e3)
    (cherry picked from commit ba89d27793c2d3a26ad95642660fa9bd820ed3be)

tags: added: in-stable-train

Reviewed: https://review.opendev.org/725892
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=330911cee48b5105ec121d96b23aed197551b561
Submitter: Zuul
Branch: stable/stein

commit 330911cee48b5105ec121d96b23aed197551b561
Author: Colleen Murphy <email address hidden>
Date: Thu Apr 16 20:35:46 2020 -0700

    Ensure OAuth1 authorized roles are respected

    Without this patch, when an OAuth1 request token is authorized with a
    limited set of roles, the roles for the access token are ignored when
    the user uses it to request a keystone token. This means that user of an
    access token can use it to escallate their role assignments beyond what
    was authorized by the creator. This patch fixes the issue by ensuring
    the token model accounts for an OAuth1-scoped token and correctly
    populating the roles for it.

    Change-Id: I02f9836fbd4d7e629653977fc341476cfd89859e
    Closes-bug: #1873290
    (cherry picked from commit 6c73690f779a42a5c62914b6bc37f0ac2f41a3e3)
    (cherry picked from commit ba89d27793c2d3a26ad95642660fa9bd820ed3be)
    (cherry picked from commit 5ff52dbaa2082991d229d8557a8e4b65256d6c53)

tags: added: in-stable-stein

Reviewed: https://review.opendev.org/725894
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=10bc689a6796f85c44d19e0c18f0e37b0a87474c
Submitter: Zuul
Branch: stable/rocky

commit 10bc689a6796f85c44d19e0c18f0e37b0a87474c
Author: Colleen Murphy <email address hidden>
Date: Thu Apr 16 20:35:46 2020 -0700

    Ensure OAuth1 authorized roles are respected

    Without this patch, when an OAuth1 request token is authorized with a
    limited set of roles, the roles for the access token are ignored when
    the user uses it to request a keystone token. This means that user of an
    access token can use it to escallate their role assignments beyond what
    was authorized by the creator. This patch fixes the issue by ensuring
    the token model accounts for an OAuth1-scoped token and correctly
    populating the roles for it.

    Modified to work with older test helper function:

      keystone/tests/unit/test_v3_oauth1.py

    Change-Id: I02f9836fbd4d7e629653977fc341476cfd89859e
    Closes-bug: #1873290
    (cherry picked from commit 6c73690f779a42a5c62914b6bc37f0ac2f41a3e3)
    (cherry picked from commit ba89d27793c2d3a26ad95642660fa9bd820ed3be)
    (cherry picked from commit 5ff52dbaa2082991d229d8557a8e4b65256d6c53)
    (cherry picked from commit 2483a578a80a916d9f5acd672d85830385b236e2)

tags: added: in-stable-rocky

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

commit fac58fdfbe31a5b93ef65b70927b3df632c689c9
Author: Colleen Murphy <email address hidden>
Date: Thu Apr 16 20:35:46 2020 -0700

    Ensure OAuth1 authorized roles are respected

    Without this patch, when an OAuth1 request token is authorized with a
    limited set of roles, the roles for the access token are ignored when
    the user uses it to request a keystone token. This means that user of an
    access token can use it to escallate their role assignments beyond what
    was authorized by the creator. This patch fixes the issue by ensuring
    the token model accounts for an OAuth1-scoped token and correctly
    populating the roles for it.

    Modified to work with older test helper function:

      keystone/tests/unit/test_v3_oauth1.py

    Conflicts:

      keystone/models/token_model.py

      The keystone token model was refactored in the Rocky release. This
      commit only backports the test so that we have test coverage against
      the bug and proves there wasn't a regression in Queens. As such, the
      code changes to token_model.py (where the bug was introduced) are not
      applicable to Queens.

      releasenotes/notes/bug-1873290-ff7f8e4cee15b75a.yaml

      Removed the release note since there isn't anything to signal to
      operators regarding a vulnerability. We're only adding test coverage
      to prove that stable/queens isn't vulnerable.

    Change-Id: I02f9836fbd4d7e629653977fc341476cfd89859e
    Closes-bug: #1873290
    (cherry picked from commit 6c73690f779a42a5c62914b6bc37f0ac2f41a3e3)
    (cherry picked from commit ba89d27793c2d3a26ad95642660fa9bd820ed3be)
    (cherry picked from commit 5ff52dbaa2082991d229d8557a8e4b65256d6c53)
    (cherry picked from commit 2483a578a80a916d9f5acd672d85830385b236e2)
    (cherry picked from commit 10bc689a6796f85c44d19e0c18f0e37b0a87474c)

tags: added: in-stable-queens

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

commit 7653847a04e56555b8d172a3d5c76a95533cdec7
Author: Colleen Murphy <email address hidden>
Date: Thu Apr 16 20:35:46 2020 -0700

    Ensure OAuth1 authorized roles are respected

    Without this patch, when an OAuth1 request token is authorized with a
    limited set of roles, the roles for the access token are ignored when
    the user uses it to request a keystone token. This means that user of an
    access token can use it to escallate their role assignments beyond what
    was authorized by the creator. This patch fixes the issue by ensuring
    the token model accounts for an OAuth1-scoped token and correctly
    populating the roles for it.

    Modified to work with older test helper function:

      keystone/tests/unit/test_v3_oauth1.py

    Conflicts:

      keystone/models/token_model.py

      The keystone token model was refactored in the Rocky release. This
      commit only backports the test so that we have test coverage against
      the bug and proves there wasn't a regression in Queens. As such, the
      code changes to token_model.py (where the bug was introduced) are not
      applicable to Pike.

      releasenotes/notes/bug-1873290-ff7f8e4cee15b75a.yaml

      Removed the release note since there isn't anything to signal to
      operators regarding a vulnerability. We're only adding test coverage
      to prove that stable/queens isn't vulnerable.

    Change-Id: I02f9836fbd4d7e629653977fc341476cfd89859e
    Closes-bug: #1873290
    (cherry picked from commit 6c73690f779a42a5c62914b6bc37f0ac2f41a3e3)
    (cherry picked from commit ba89d27793c2d3a26ad95642660fa9bd820ed3be)
    (cherry picked from commit 5ff52dbaa2082991d229d8557a8e4b65256d6c53)
    (cherry picked from commit 2483a578a80a916d9f5acd672d85830385b236e2)
    (cherry picked from commit 10bc689a6796f85c44d19e0c18f0e37b0a87474c)
    (cherry picked from commit d590441ce6897a7a169db7262eb17bcd5d90bcd2)

tags: added: in-stable-pike
jichenjc (jichenjc) wrote :

I see the code is refactory at

commit 04a54966578c1fa17bb1b962769a87c1213ff21f
Author: Lance Bragstad <email address hidden>
Date: Thu Apr 5 16:49:52 2018 +0000

    Introduce new TokenModel object

so the fix are based on the refactoried code
we are still maintaining internal newton code which is before the refactory
will that be affect by this issue or not? can you help to comment? THanks

On 2020-07-10 03:02:14 -0000 (-0000), jichenjc wrote:
[...]
> we are still maintaining internal newton code which is before the
> refactory will that be affect by this issue or not? can you help
> to comment? THanks

You may find it much easier to backport the fix from the stable/pike
branch:

https://opendev.org/openstack/keystone/commit/7653847a04e56555b8d172a3d5c76a95533cdec7

Checking out the newton-eol tag, `git cherry-pick 7653847` applies
cleanly for me with no conflicts. Note I have not tested this patch
on Newton, and you might want additional feedback from Keystone devs
as to whether this is safe (or even necessary) on Newton.
--
Jeremy Stanley

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

Bug attachments