Bug #1677723 “[OSSA-2017-004] federated user gets wrong role (CV...” : Bugs : OpenStack Identity (keystone)

Boris Bobrov (bbobrov) wrote on 2017-03-30:

#1

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) wrote on 2017-03-30:

#2

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

Boris Bobrov (bbobrov) wrote on 2017-03-31:

#3

1677723.patch Edit (2.5 KiB, text/plain)

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

Boris Bobrov (bbobrov) wrote on 2017-03-31:

#4

0001-Expose-issue-with-federated-user-getting-wrong-role.patch Edit (2.5 KiB, text/plain)

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

Boris Bobrov (bbobrov) wrote on 2017-03-31:

#5

0002-Do-not-fetch-group-assignments-without-groups.patch Edit (1.3 KiB, text/plain)

Boris Bobrov (bbobrov) wrote on 2017-03-31:

#6

0001-Do-not-fetch-group-assignments-without-groups.patch Edit (3.4 KiB, text/plain)

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

David Stanek (dstanek) wrote on 2017-03-31:

#7

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) wrote on 2017-04-02:

#8

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) wrote on 2017-04-03:

#9

> 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) wrote on 2017-04-03:

#10

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) wrote on 2017-04-03:

#11

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) wrote on 2017-04-05:

#12

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

Tristan Cacqueray (tristan-cacqueray) on 2017-04-06

Changed in ossa:
assignee:	nobody → Tristan Cacqueray (tristan-cacqueray)
status:	Incomplete → In Progress

Tristan Cacqueray (tristan-cacqueray) on 2017-04-06

summary:

- federated user gets wrong role
+ federated user gets wrong role (CVE-2017-2673)

Tristan Cacqueray (tristan-cacqueray) wrote on 2017-04-06: Re: federated user gets wrong role (CVE-2017-2673)

#13

cve-2017-2673-stable-ocata.patch Edit (3.4 KiB, text/plain)

Attaching stable/ocata cherry-pick for completeness

Tristan Cacqueray (tristan-cacqueray) wrote on 2017-04-06:

#14

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

Jeremy Stanley (fungi) wrote on 2017-04-06:

#15

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) wrote on 2017-04-06:

#16

Absolutely, thanks for the reminder.

Changed in keystone:
status:	New → Confirmed
importance:	Undecided → Critical
assignee:	nobody → Boris Bobrov (bbobrov)
milestone:	none → pike-1

Lance Bragstad (lbragstad) wrote on 2017-04-06:

#17

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

Tristan Cacqueray (tristan-cacqueray) on 2017-04-07

Changed in ossa:
status:	In Progress → Fix Committed
importance:	Undecided → Critical

Boris Bobrov (bbobrov) wrote on 2017-04-11:

#18

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) wrote on 2017-04-11:

#19

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) wrote on 2017-04-11:

#20

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) wrote on 2017-04-11:

#21

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

Tristan Cacqueray (tristan-cacqueray) wrote on 2017-04-12:

#22

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) wrote on 2017-04-12:

#23

Subscribing tsuter who came to the same conclusion.

Tristan Cacqueray (tristan-cacqueray) wrote on 2017-04-12:

#24

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) wrote on 2017-04-12:

#25

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) wrote on 2017-04-13:

#26

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) wrote on 2017-04-16:

#27

0001-Do-not-fetch-group-assignments-without-groups.patch Edit (5.1 KiB, text/plain)

Please review. I've added a test.

Tristan Cacqueray (tristan-cacqueray) wrote on 2017-04-17:

#28

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.