[OSSA-2017-004] federated user gets wrong role (CVE-2017-2673)

[Boris Bobrov]

Keystone stable/ocata. Federation is used with the following mapping: http://paste.openstack.org/show/ou0GTGp9fTQIzcHtixUU/ . As you can see, all users get a _member_ role, which has almost no permissions, and this role is granted for the newly-created project.

User admin@Default, with role admin in project admin@Default wants to do something for project "Dev project for <email address hidden>". admin@Default assigns themselves role admin on the project (openstack role assign --user admin --user-domain Default --project-id <id for Dev project for unprivileged@> admin)

At this point, if federated user "<email address hidden>" gets a new token by going through federation and then scopes the token, they get a token with role admin. Here is an example of such token: http://paste.openstack.org/show/7vncdFywNmi6WZ9S7KXX/. In horizon it means they can see and do everything admin can do.

There is no record about unprivileged user having role admin in the database. This assignment is not displayed in `openstack role assignment list`. The assignment only gets effective when a scoped token is requested.

Workaround for the issue is to remove role admin from admin@Default on project "Dev project for unpriveledged@". Unprivileged user immediately loses admin privileges; the token is still valid, but there is no role "admin" in GET /v3/auth/tokens .

[Boris Bobrov (bbobrov)]

To use this vulnerability, attacker can ask admin get a role in their project (hey admin@Default, could you please have a look at instances in my project?) and get all admin privileges as soon as admin assigns themselves role at attacker's project.

[Jeremy Stanley (fungi)]

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.

[Boris Bobrov (bbobrov)]

Here is a unit test to demonstrate expected behavior; it fails today.

[Boris Bobrov (bbobrov)]

Here is a unit test and a fix for the bug.

[Boris Bobrov (bbobrov)]

I have reworked it a bit; here is a patch and tests in a single commit.

[David Stanek (dstanek)]

I just tested the patch and it appears to work. It's very worrisome looking at the code. I honestly can't tell if there are other situations where we could have the same problem.

[Tristan Cacqueray (tristan-cacqueray)]

Could this be caused by a special configuration, or is this happening for all federation setup?
It's surprising that the group_ids is empty, shouldn't it contains the _member_ id ?

Here is an early impact description draft:

Title: Incorrect role assignment with federated Keystone
Reporter: Boris Bobrov (Mirantis)
Products: Keystone
Affects: >=9.0.0 <=9.3.0, >=10.0.0 <=10.0.1, ==11.0.0

Description:
Boris Bobrov from Mirantis reported a vulnerability in Keystone Federation. An authenticated user may receive all the roles assigned with the user's project regardless of the federation mapping. For example, by requesting an admin user to get a role in their project, the user may be granted the admin privileges for new scoped tokens. All setups using the Keystone federation are affected.

[Boris Bobrov (bbobrov)]

> Reporter:

Reporter: Boris Bobrov (Mail.Ru) and Boris Bobrov from Mail.Ru

> Could this be caused by a special configuration, or is this happening for all federation setup?

This is happening for federation setup where both conditions are satisfied:
 - auto-provisioning capabilities are used ("project" JSON object is used)
 - there are rules in which group-based assignments are NOT used ("group" JSON object is not used).

> Affects: >=9.0.0 <=9.3.0, >=10.0.0 <=10.0.1, ==11.0.0

Mitaka and Newton are not affected, Ocata and Pike are affected.

[Tristan Cacqueray (tristan-cacqueray)]

Thanks for the precision Boris, here is the updated impact description:

Title: Incorrect role assignment with federated Keystone
Reporter: Boris Bobrov (Mail.Ru)
Products: Keystone
Affects: ==11.0.0

Description:
Boris Bobrov from Mail.Ru reported a vulnerability in Keystone Federation. An authenticated user may receive all the roles assigned to the user's project regardless of the federation mapping when there are rules in which group-based assignments are not used. For example, by requesting an admin user to get a role in their project, the user may be granted the admin privileges for new scoped tokens. All setups using the Keystone federation with projects auto-provisioning and no group based assignments rules are affected.

[Jeremy Stanley (fungi)]

Tristan's updated impact description in comment #10 looks good to me, though we should probably wait to request a CVE assignment from our CNA until keystone-coresec reviewers have triaged and confirmed the report.

[Lance Bragstad (lbragstad)]

I've confirmed the patch from comment #6 addresses the issue. Thanks for the quick work here, Boris.

[Tristan Cacqueray (tristan-cacqueray)]

Attaching stable/ocata cherry-pick for completeness

[Tristan Cacqueray (tristan-cacqueray)]

Proposed disclosure date: 2017-04-12, 1500 UTC

[Jeremy Stanley (fungi)]

Just for completeness, Lance (or anyone from keystone-coresec), can you please triage the Keystone bugtask for this report and confirm that you consider it a vulnerability in the software? I know you've confirmed that the attached patch fixes the reported behavior, but haven't actually said anywhere that it's unintended behavior and so I want to make sure we don't press forward announcing something that isn't actually a vulnerability. Thanks!

[Lance Bragstad (lbragstad)]

Absolutely, thanks for the reminder.

[Lance Bragstad (lbragstad)]

Marking this as Critical based on the situation Boris outlined in comment #1.

[Boris Bobrov (bbobrov)]

I was contacted by folks from Mirantis. They found out that:

1. This feature is not directly tied to auto-provisioning
2. There are mappings that don't use auto-provisioning and are still vulnerable to issue with incorrect roles being assigned.

I believe that their issue and mine are actually the same issue. My patch still fixes the bug, but now the affected versions are Mitaka, Newton and Ocata.

For example, people with mapping like http://paste.openstack.org/show/606171/ are affected too.
As far as i understand, all installations with mappings not using key "groups" are affected.

I suggest to add the person who reported the issue to me to this bugreport. His profile at lp is https://launchpad.net/~dmitrymex

[Lance Bragstad (lbragstad)]

Based on comment #18, we need to re-spin the proposed patch in comment #6 to make it test a mapping that doesn't enable auto-provisioning. We should certainly keep the auto-provisioning test coverage, but we should add a test case that shows this can be done with mappings that don't rely on that feature.

Jeremy and Tristan,

Do we need to extend the proposed disclosure date if the communication needs to be amended?

[Lance Bragstad (lbragstad)]

FWIW - I wouldn't be opposed to adding the person from Mirantis to this report for the sake of knowing the fix works for all cases.

[Boris Bobrov (bbobrov)]

I am being told that Mitaka is not affected, only Newton.

[Tristan Cacqueray (tristan-cacqueray)]

I've subscribed dmitrymex, please do add anyone needed on this issue.

The embargo disclosure is on hold, we'll need a new disclosure date once the patches are ready.

[Tristan Cacqueray (tristan-cacqueray)]

Subscribing tsuter who came to the same conclusion.

[Tristan Cacqueray (tristan-cacqueray)]

New impact description with Newton affect and without the auto-provisioning mention:

Title: Incorrect role assignment with federated Keystone
Reporter: Boris Bobrov (Mail.Ru)
Products: Keystone
Affects: >=10.0.0 <=10.0.1, ==11.0.0

Description:
Boris Bobrov from Mail.Ru reported a vulnerability in Keystone Federation. An authenticated user may receive all the roles assigned to the user's project regardless of the federation mapping when there are rules in which group-based assignments are not used. For example, by requesting an admin user to get a role in their project, the user may be granted the admin privileges for new scoped tokens. All setups using the Keystone federation without group based assignments rules are affected.

[Tim Suter (tsuter)]

re: comment#21 and Mitaka being affected

While I haven't come to the conclusion that the bug can be triggered in Mitaka, I'm of the opinion that the function get_roles_for_groups() should still have the same patch as the other affected versions (even without test cases to drop engineering load if need be).

based on:
a) the patch is simple and best practice
b) the function is sensitive
c) we may not have covered all edge cases for deployment scenarios

Maybe I am a little bias considering Mitaka's EOL date

[Dmitry Mescheryakov (dmitrymex)]

Re if Mitaka is affected:

When we tried to get unscoped token in Mitaka, we failed with the following trace:

 [req-a3e0e824-2c97-466a-b4c2-38079b1f0fa9 - - - - -] Unable to find valid groups while using mapping ldap-map
 Traceback (most recent call last):
   File "/keystone/keystone/auth/plugins/mapped.py", line 67, in authenticate
     self.identity_api)
   File "/keystone/keystone/auth/plugins/mapped.py", line 160, in handle_unscoped_token
     utils.validate_groups_cardinality(group_ids, mapping_id)
   File "/keystone/keystone/federation/utils.py", line 259, in validate_groups_cardinality
     raise exception.MissingGroups(mapping_id=mapping_id)
 MissingGroups: Unable to find valid groups while using mapping ldap-map

(got the trace via additional logging). I.e. user with no groups was rejected to log in. I don't know a way to get scoped token without obtaining unscoped one first. If that is indeed impossible, than Mitaka is not affected.

On the other hand, merging the fix into Mitaka should not break anything.

[Boris Bobrov (bbobrov)]

Please review. I've added a test.

[Tristan Cacqueray (tristan-cacqueray)]

Beside a pep8 error, tox verified patch #27 on stable/ocata.

./keystone/tests/unit/test_v3_federation.py:1940:5: E303 too many blank lines (2)
    def test_issue_unscoped_token_malformed_environment(self):
    ^

Considering we may not have covered all the edge cases, it seems like a good idea to mention Mitaka as affected. Though the branch will probably be EOLed by the time the patch are proposed on gerrit, and the tests doesn't applies cleanly on mitaka's branch.

[Boris Bobrov (bbobrov)]

Thank you, updated

[Boris Bobrov (bbobrov)]

Mitaka is probably affected too, if someone directly gets a project-scoped federated token, but i cannot verify that because of lack of environment. The fix should be the same, but the unit test needs to be heavily changed. I will do my best to write them soon, but feel free to do it if you need it sooner.

[Boris Bobrov (bbobrov)]

Mitaka is not affected. It is impossible to get a project-scoped token skipping the unscoped one, and getting unscoped one fails (there is a test for that).

[Tim Suter (tsuter)]

Awesome, thanks for that clarification Boris.

[Tristan Cacqueray (tristan-cacqueray)]

Thanks for the quick feedback, so the impact description proposed in comment #24 is still valid.

Assuming the patches proposed in #29, #30 and #31 are pre-approved, I'll follow-up the pre-OSSA with this new disclosure date: 2017-04-25, 1500 UTC.

@horizon-coresec, please review the proposed patches.

[Lance Bragstad (lbragstad)]

Thanks Breton, I'll review the patches proposed in #29, #30, and #31 today.

[Lance Bragstad (lbragstad)]

The patches in comments #29, #30, and #31 check out for me. The only comment I'd make would be to not specifically reference the bug number in a doc string while in a public review system, since we don't have a known workaround available (unless folks change their mappings). I'm not sure how sensitive that is, or what the attack vector is like given the time window of review, but I'll defer to the opinion of others. Otherwise, the code works and the tests are clean and concise. The technical aspects of the patch address the bug.

I approve based on all technical aspects of all proposed patches (#29, #30, #31). Thanks, Boris!

[Tristan Cacqueray (tristan-cacqueray)]

Lance, the bug will be made public prior to submit patch to gerrit (e.g.: https://security.openstack.org/vmt-process.html#open-bug-push-patches ), so it seems acceptable to reference the original bug report in doc strings.

Thanks for the review!

[Lance Bragstad (lbragstad)]

Adding Samuel to this bug report so that we have another core reviewer able to approve the changes.

[Lance Bragstad (lbragstad)]

Proposed fix to master: https://review.openstack.org/#/c/459705/
Proposed fix to stable/newton: https://review.openstack.org/#/c/459713/
Proposed fix to stable/ocata: https://review.openstack.org/#/c/459732/

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/459742

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/459742
Committed: https://git.openstack.org/cgit/openstack/ossa/commit/?id=53a4f33f8872b5bad05d26e63c323a31ad8189b4
Submitter: Jenkins
Branch: master

commit 53a4f33f8872b5bad05d26e63c323a31ad8189b4
Author: Tristan Cacqueray <email address hidden>
Date: Tue Apr 25 14:02:09 2017 +0000

    Adds OSSA-2017-004 (CVE-2017-2673)

    Change-Id: I8c1166125c7c1e206eefbe518be7bff3376c055c
    Closes-Bug: #1677723

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/459705
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=2139639eeabc8f6941f4461fc87d609cde3118c2
Submitter: Jenkins
Branch: master

commit 2139639eeabc8f6941f4461fc87d609cde3118c2
Author: Boris Bobrov <email address hidden>
Date: Tue Apr 25 13:57:16 2017 +0000

    Do not fetch group assignments without groups

    Without the change, the method fetched all assignments for a project
    or domain, regardless of who has the assignment, user or group. This
    led to situation when federated user without groups could scope a token
    with other user's rules.

    Return empty list of assignments if no groups were passed.

    Closes-Bug: 1677723
    Change-Id: I65f5be915bef2f979e70b043bde27064e970349d

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/459732
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=955fd6ca3758e217d9d98480852e0014dc11e988
Submitter: Jenkins
Branch: stable/ocata

commit 955fd6ca3758e217d9d98480852e0014dc11e988
Author: Boris Bobrov <email address hidden>
Date: Tue Apr 25 14:36:12 2017 +0000

    Do not fetch group assignments without groups

    Without the change, the method fetched all assignments for a project
    or domain, regardless of who has the assignment, user or group. This
    led to situation when federated user without groups could scope a token
    with other user's rules.

    Return empty list of assignments if no groups were passed.

    Closes-Bug: 1677723
    Change-Id: I65f5be915bef2f979e70b043bde27064e970349d
    (cherry picked from commit 2139639eeabc8f6941f4461fc87d609cde3118c2)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/459713
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=05a129e54573b6cbda1ec095f4526f2b9ba90a90
Submitter: Jenkins
Branch: stable/newton

commit 05a129e54573b6cbda1ec095f4526f2b9ba90a90
Author: Boris Bobrov <email address hidden>
Date: Tue Apr 25 14:20:36 2017 +0000

    Do not fetch group assignments without groups

    Without the change, the method fetched all assignments for a project
    or domain, regardless of who has the assignment, user or group. This
    led to situation when federated user without groups could scope a token
    with other user's rules.

    Return empty list of assignments if no groups were passed.

    Closes-Bug: 1677723
    Change-Id: I65f5be915bef2f979e70b043bde27064e970349d
    (cherry picked from commit 2139639eeabc8f6941f4461fc87d609cde3118c2)

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/keystone 11.0.1 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/keystone 12.0.0.0b2 development milestone.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/keystone 10.0.2 release.