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

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.

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

Corrected the patch to account for bug 1872755

The included ps looks ok to me.

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

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

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.

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

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.

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

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.

lgtm

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?

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.

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.

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

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

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?

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

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.

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

notification sent for this one.

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

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.

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

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.

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?

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

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": "!"

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

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

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

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

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

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

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

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

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

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)

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

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)

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)

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)

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)

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)

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

THanks for the comments, Jeremy, from the link above, it says:

https://opendev.org/openstack/keystone/commit/7653847a04e56555b8d172a3d5c76a95533cdec7
```
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.
```
so I think the reason you can cherry pick

sorry, hit `post ` too fast
so from the comments I think the code logic is changed from Pike
which means, actually the code before Pike should not be affected
that's the reason why only a test case is added but no real code updated
guess that's the reason ..

so it means it will not affect keystone which is prior to Pike
while the CVE says all keystone prior to 15.0.0..

jichenjc: Ahh, yes, a closer reading of the patch indicates you're correct. This vulnerability is not, from what I can see, present in releases up through Queens.

Generally our advisories assume that if the oldest supported release (at time of writing that was 15.0.0 codenamed Rocky) is vulnerable then all versions prior to it are also vulnerable. In this case it sounds like the vulnerability was introduced in Rocky, so versions prior to it are not at risk.

That said, it is probably a good idea to assume there are other unpatched vulnerabilities in Newton, as we don't issue advisories for any which get discovered only in unmaintained versions of our software (including stable branches in an "extended maintenance" state).

Er, sorry, oldest maintained release at time of writing for OSSA-2020-005 was 15.0.0 codenamed Stein. Since the vulnerability also affected the 14.0.0 Rocky release where it was introduced, a fix was backported to the stable/rocky branch (under extended maintenance) as a courtesy, but no new point release will be tagged for it per OpenStack's extended maintenance policy.

Jeremy:
ok, got it , really appreciate your kindly help and time in providing the info
thanks a lot ~

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

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

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