OpenStack Identity (keystone)

Token invalidation in case of role grant/revoke should be limited to affected tenant

Series essex
Bug #1050025

Bug #1050025 reported by Russell Bryant on 2012-09-12

This bug affects 1 person

	Status	Importance	Assigned to	Milestone
OpenStack Identity (keystone)	Fix Released	Medium	Dolph Mathews	OpenStack Identity (keystone) 2012.2 "folsom"
Essex	Fix Released	Medium	Alan Pevec	OpenStack Identity (keystone) 2012.1.3
keystone (Ubuntu)	Fix Released	Undecided	Unassigned
Precise	Fix Released	Undecided	Unassigned

Bug Description

We just released this security advisory:
https://lists.launchpad.net/openstack/msg16659.html

Soren Hansen brought up a potential problem here:
https://lists.launchpad.net/openstack/msg16662.html

Although this can't be used as an attack vector (see comments below), token invalidation should really be limited to affected tenant.

See original description

Tags:

Related branches

lp:~openstack-ubuntu-testing/keystone/precise-essex-proposed

Merged into lp:~ubuntu-server-dev/keystone/essex at revision 100

Ubuntu Server Developers: Pending requested 2012-03-16

lp:~yolanda.robla/ubuntu/precise/keystone/essex-sru

Merged into lp:ubuntu/precise-updates/keystone

James Page: Approve on 2012-12-18

lp:ubuntu/precise-proposed/keystone

CVE References

Russell Bryant (russellb) on 2012-09-12

security vulnerability:	no → yes
Changed in keystone:
milestone:	none → folsom-rc1

Revision history for this message

Thierry Carrez (ttx) wrote on 2012-09-13:

Yeah, I was kinda supposing it would only invalidate the tokens for the tenant the role was granted to/revoked from... but not sure anymore now.

Changed in keystone:
importance:	Undecided → High
status:	New → Incomplete

Revision history for this message

Thierry Carrez (ttx) wrote on 2012-09-13:

Looking at the code, definitely looks like it's not limited by tenant :/

Dolph Mathews (dolph) on 2012-09-13

Changed in keystone:
status:	Incomplete → Confirmed

Revision history for this message

Dolph Mathews (dolph) wrote on 2012-09-13:

I'm not quite sure what Soren means by "everyone's tokens," but I can confirm that all tokens for the specific user are revoked -- revocation is **not** limited to the specific tenant. While not 100% desirable, I don't see how it's a security vulnerability..?

I would definitely prefer to limit token revocation to the specific tenant, however.

Revision history for this message

Joseph Heck (heckj) wrote on 2012-09-13:

This patch isn't invalidating all tokens - just the tokens for the relevant user.

Russel and/or Thierry - can you explain why this is a bug? I don't believe this bug is valid. not confirmed.

Revision history for this message

Joseph Heck (heckj) wrote on 2012-09-13:

[08:39am] ttx: user A has a token for tenant B. Admin of tenant C grants A access to C, effectively disabling the token A had for B ?
[08:39am] dolphm: ttx: sure, the user can just re-auth though
[08:39am] ttx: dolphm: letting /anyone/ disabling any token sounds a bit... abusive to me
[08:39am] ttx: and potentially something a bad guy would want to do
[08:40am] ayoung: dolphm, why not filter the list by tenant_id?
[08:40am] ttx: not very critical in its effect, for sure
[08:40am] dolphm: ttx: "anyone" being any admin, and "any token" being for a specific user
...
[08:43am] ttx: dolphm: oh. So a random user can't become the "admin" of a tenant and grant random users access to his tenant ?
[08:43am] dolphm: ttx: not in identity api v2 / current keystone impl
[08:43am] ttx: dolphm: you have to be the god of all keystone to grant roles ? In which case I agree there is no vector
[08:43am] ttx: and no impact
[08:43am] heckj: ttx: with the V2 API, that's correct

Changed in keystone:
importance:	High → Medium
milestone:	folsom-rc1 → none

Revision history for this message

Joseph Heck (heckj) wrote on 2012-09-13:

This method invoked, when updating should be limiting it's impact to the tokens associated with the user and tenant, not all tokens for the user.

Revision history for this message

Thierry Carrez (ttx) wrote on 2012-09-13:

Ok, so apparently you have to be an admin of all Keystone to grant or revoke roles. Since in this case you can just revoke any token anyway, there is no vulnerability here.

The bug is still valid: invalidation of tokens in that scenario should be limited to affected tenant.

Dolph Mathews (dolph) on 2012-09-13

Changed in keystone:
assignee:	nobody → Dolph Mathews (dolph)

Thierry Carrez (ttx) on 2012-09-13

summary:	- Potential problem with fix for "Revoking a role does not affect existing - tokens (CVE-2012-4413)" + Token invalidation in case of role grant/revoke should be limited to + affected tenant
security vulnerability:	yes → no
description:	updated

Joseph Heck (heckj) on 2012-09-13

Changed in keystone:
milestone:	none → folsom-rc1

Revision history for this message

OpenStack Infra (hudson-openstack) wrote on 2012-09-13: Fix proposed to keystone (master)

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

Changed in keystone:
status:	Confirmed → In Progress

Revision history for this message

OpenStack Infra (hudson-openstack) wrote on 2012-09-13: Fix merged to keystone (master)

Reviewed: https://review.openstack.org/12953
Committed: http://github.com/openstack/keystone/commit/4e1a0867f9e9f42dd7c2abe3a10ca8a8f7dddce3
Submitter: Jenkins
Branch: master

commit 4e1a0867f9e9f42dd7c2abe3a10ca8a8f7dddce3
Author: Dolph Mathews <email address hidden>
Date: Thu Sep 13 11:59:11 2012 -0500

Limit token revocation to tenant (bug 1050025)

Change-Id: I7ebe0192b4900ad9475119a6d582233b37b31fb4

Changed in keystone:
status:	In Progress → Fix Committed

Joseph Heck (heckj) on 2012-09-13

tags:	added: essexbackport
tags:	added: essex-backport removed: essexbackport

Revision history for this message

OpenStack Infra (hudson-openstack) wrote on 2012-09-13: Fix proposed to keystone (stable/essex)

#10

Fix proposed to branch: stable/essex
Review: https://review.openstack.org/12995

Revision history for this message

OpenStack Infra (hudson-openstack) wrote on 2012-09-14: Fix merged to keystone (stable/essex)

#11

Reviewed: https://review.openstack.org/12995
Committed: http://github.com/openstack/keystone/commit/176ee9bce7557937710c8ec8086ff61cc751cf0f
Submitter: Jenkins
Branch: stable/essex

commit 176ee9bce7557937710c8ec8086ff61cc751cf0f
Author: Dolph Mathews <email address hidden>
Date: Thu Sep 13 11:59:11 2012 -0500

Limit token revocation to tenant (bug 1050025)

Change-Id: I7ebe0192b4900ad9475119a6d582233b37b31fb4

Thierry Carrez (ttx) on 2012-09-14

Changed in keystone:
status:	Fix Committed → Fix Released

Thierry Carrez (ttx) on 2012-09-27

Changed in keystone:
milestone:	folsom-rc1 → 2012.2

Yolanda Robla (yolanda.robla) on 2012-12-11

Changed in keystone (Ubuntu):
status:	New → Fix Released

Adam Gandelman (gandelman-a) on 2012-12-12

Changed in keystone (Ubuntu Precise):
status:	New → Confirmed

Revision history for this message

Brian Murray (brian-murray) wrote on 2013-05-09: Please test proposed package

#12

Hello Russell, or anyone else affected,

Accepted keystone into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/keystone/2012.1.3+stable-20130423-f48dd0fc-0ubuntu1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in keystone (Ubuntu Precise):
status:	Confirmed → Fix Committed
tags:	added: verification-needed

Revision history for this message

Yolanda Robla (yolanda.robla) wrote on 2013-05-16: Verification report.

#13

Please find the attached test log from the Ubuntu Server Team's CI infrastructure. As part of the verification process for this bug, Keystone has been deployed and configured across multiple nodes using precise-proposed as an installation source. After successful bring-up and configuration of the cluster, a number of exercises and smoke tests have be invoked to ensure the updated package did not introduce any regressions. A number of test iterations were carried out to catch any possible transient errors.

Please Note the list of installed packages at the top and bottom of the report.

For records of upstream test coverage of this update, please see the Jenkins links in the comments of the relevant upstream code-review(s):

Trunk review: https://review.openstack.org/12953
Stable review: https://review.openstack.org/12995

As per the provisional Micro Release Exception granted to this package by the Technical Board, we hope this contributes toward verification of this update.

Revision history for this message

Yolanda Robla (yolanda.robla) wrote on 2013-05-16:

#14

2012.1.3+stable-20130423-f48dd0fc-0ubuntu1.log Edit (111.3 KiB, text/plain)

Test coverage log.

tags:

added: verification-done
removed: verification-needed

Revision history for this message

Scott Kitterman (kitterman) wrote on 2013-05-16: Update Released

#15

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

Revision history for this message

Launchpad Janitor (janitor) wrote on 2013-05-16:

#16

This bug was fixed in the package keystone - 2012.1.3+stable-20130423-f48dd0fc-0ubuntu1

---------------
keystone (2012.1.3+stable-20130423-f48dd0fc-0ubuntu1) precise-proposed; urgency=low

  * Resynchronize with stable/essex (LP: #1089488):
    - [7402f5e] EC2 authentication does not ensure user or tenant is enabled
      LP: 1121494
    - [8945567] DoS through XML entity expansion (CVE-2013-1664) LP: 1100282
    - [7b5b72f] Add size validations for /tokens.
    - [ef1e682] docutils 0.10 incompatible with sphinx 1.1.3 LP: 1091333
    - [8735009] Removing user from a tenant isn't invalidating user access to
      tenant (LP: #1064914)
    - [025b1d5] Jenkins jobs fail because of incompatibility between sqlalchemy-
      migrate and the newest sqlalchemy-0.8.0b1 (LP: #1073569)
    - [ddb4019] Open 2012.1.4 development
    - [0e1f05e] memcache driver needs protection against unicode user keys
      (LP: #1056373)
    - [176ee9b] Token invalidation in case of role grant/revoke should be
      limited to affected tenant (LP: #1050025)
    - [58ac669] Token validation includes revoked roles (CVE-2012-4413)
      (LP: #1041396)
    - [cd1e48a] Memcached Token Backend does not support list tokens
      (LP: #1046905)
    - [5438d3b] Update user's default tenant partially succeeds without authz
      (LP: #1040626)
  * Dropped patches, superseeded by new snapshot:
    - debian/patches/CVE-2013-0282.patch [7402f5e]
    - debian/patches/CVE-2013-1664+1665.patch [8945567]
    - debian/patches/keystone-CVE-2012-5571.patch [8735009]
    - debian/patches/keystone-CVE-2012-4413.patch [58ac669]
    - debian/patches/keystone-CVE-2012-3542.patch [5438d3b]
  * Refreshed patches:
    - debian/patches/CVE-2013-0247.patch
    - debian/patches/fix-ubuntu-tests.patch
-- Yolanda <email address hidden> Tue, 23 Apr 2013 10:30:16 +0200