| 2017-03-30 19:58:03 |
Boris Bobrov |
bug |
|
|
added bug |
| 2017-03-30 20:45:56 |
Jeremy Stanley |
description |
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 unpriveledged@corp.mail.ru". 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 "unpriveledged@corp.mail.ru" 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 . |
This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added to the bug as attachments.
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 unpriveledged@corp.mail.ru". 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 "unpriveledged@corp.mail.ru" 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 . |
|
| 2017-03-30 20:46:08 |
Jeremy Stanley |
bug task added |
|
ossa |
|
| 2017-03-30 20:46:33 |
Jeremy Stanley |
ossa: status |
New |
Incomplete |
|
| 2017-03-30 20:46:50 |
Jeremy Stanley |
bug |
|
|
added subscriber Keystone Core security contacts |
| 2017-03-31 07:15:28 |
Boris Bobrov |
attachment added |
|
1677723.patch https://bugs.launchpad.net/keystone/+bug/1677723/+attachment/4851124/+files/1677723.patch |
|
| 2017-03-31 08:01:01 |
Boris Bobrov |
attachment added |
|
0001-Expose-issue-with-federated-user-getting-wrong-role.patch https://bugs.launchpad.net/keystone/+bug/1677723/+attachment/4851160/+files/0001-Expose-issue-with-federated-user-getting-wrong-role.patch |
|
| 2017-03-31 08:01:25 |
Boris Bobrov |
attachment added |
|
0002-Do-not-fetch-group-assignments-without-groups.patch https://bugs.launchpad.net/keystone/+bug/1677723/+attachment/4851161/+files/0002-Do-not-fetch-group-assignments-without-groups.patch |
|
| 2017-03-31 08:05:52 |
Boris Bobrov |
attachment added |
|
0001-Do-not-fetch-group-assignments-without-groups.patch https://bugs.launchpad.net/keystone/+bug/1677723/+attachment/4851162/+files/0001-Do-not-fetch-group-assignments-without-groups.patch |
|
| 2017-04-06 01:43:42 |
Tristan Cacqueray |
ossa: assignee |
|
Tristan Cacqueray (tristan-cacqueray) |
|
| 2017-04-06 01:43:49 |
Tristan Cacqueray |
ossa: status |
Incomplete |
In Progress |
|
| 2017-04-06 09:35:20 |
Tristan Cacqueray |
summary |
federated user gets wrong role |
federated user gets wrong role (CVE-2017-2673) |
|
| 2017-04-06 09:35:28 |
Tristan Cacqueray |
cve linked |
|
2017-2673 |
|
| 2017-04-06 10:20:43 |
Tristan Cacqueray |
attachment added |
|
cve-2017-2673-stable-ocata.patch https://bugs.launchpad.net/keystone/+bug/1677723/+attachment/4856067/+files/cve-2017-2673-stable-ocata.patch |
|
| 2017-04-06 12:55:14 |
Lance Bragstad |
keystone: status |
New |
Confirmed |
|
| 2017-04-06 12:55:23 |
Lance Bragstad |
keystone: importance |
Undecided |
Critical |
|
| 2017-04-06 12:55:41 |
Lance Bragstad |
keystone: assignee |
|
Boris Bobrov (bbobrov) |
|
| 2017-04-06 12:55:47 |
Lance Bragstad |
keystone: milestone |
|
pike-1 |
|
| 2017-04-07 00:53:23 |
Tristan Cacqueray |
ossa: status |
In Progress |
Fix Committed |
|
| 2017-04-07 00:53:26 |
Tristan Cacqueray |
ossa: importance |
Undecided |
Critical |
|
| 2017-04-12 00:11:19 |
Tristan Cacqueray |
bug |
|
|
added subscriber Dmitry Mescheryakov |
| 2017-04-12 03:35:31 |
Tristan Cacqueray |
bug |
|
|
added subscriber Tim Suter |
| 2017-04-16 21:30:22 |
Boris Bobrov |
attachment added |
|
0001-Do-not-fetch-group-assignments-without-groups.patch https://bugs.launchpad.net/keystone/+bug/1677723/+attachment/4863263/+files/0001-Do-not-fetch-group-assignments-without-groups.patch |
|
| 2017-04-17 16:09:32 |
Boris Bobrov |
attachment added |
|
cve-2017-2673-master.patch https://bugs.launchpad.net/keystone/+bug/1677723/+attachment/4863653/+files/cve-2017-2673-master.patch |
|
| 2017-04-17 16:09:50 |
Boris Bobrov |
attachment added |
|
cve-2017-2673-stable-ocata.patch https://bugs.launchpad.net/keystone/+bug/1677723/+attachment/4863654/+files/cve-2017-2673-stable-ocata.patch |
|
| 2017-04-17 16:10:07 |
Boris Bobrov |
attachment added |
|
cve-2017-2673-stable-newton.patch https://bugs.launchpad.net/keystone/+bug/1677723/+attachment/4863655/+files/cve-2017-2673-stable-newton.patch |
|
| 2017-04-17 16:10:38 |
Boris Bobrov |
attachment added |
|
cve-2017-2673-stable-mitaka.patch https://bugs.launchpad.net/keystone/+bug/1677723/+attachment/4863656/+files/cve-2017-2673-stable-mitaka.patch |
|
| 2017-04-17 16:25:09 |
Boris Bobrov |
attachment removed |
cve-2017-2673-stable-mitaka.patch https://bugs.launchpad.net/keystone/+bug/1677723/+attachment/4863656/+files/cve-2017-2673-stable-mitaka.patch |
|
|
| 2017-04-25 14:07:46 |
Lance Bragstad |
bug |
|
|
added subscriber Samuel de Medeiros Queiroz |
| 2017-04-25 15:00:37 |
Tristan Cacqueray |
description |
This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added to the bug as attachments.
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 unpriveledged@corp.mail.ru". 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 "unpriveledged@corp.mail.ru" 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 . |
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 unpriveledged@corp.mail.ru". 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 "unpriveledged@corp.mail.ru" 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 . |
|
| 2017-04-25 15:00:59 |
Tristan Cacqueray |
information type |
Private Security |
Public |
|
| 2017-04-25 15:31:38 |
Tristan Cacqueray |
summary |
federated user gets wrong role (CVE-2017-2673) |
[OSSA-2017-004] federated user gets wrong role (CVE-2017-2673) |
|
| 2017-04-25 15:32:50 |
OpenStack Infra |
ossa: status |
Fix Committed |
Fix Released |
|
| 2017-04-25 16:40:18 |
OpenStack Infra |
keystone: status |
Confirmed |
Fix Released |
|
| 2017-04-25 18:17:58 |
OpenStack Infra |
tags |
federation |
federation in-stable-ocata |
|
| 2017-04-25 18:18:08 |
OpenStack Infra |
tags |
federation in-stable-ocata |
federation in-stable-newton in-stable-ocata |
|
