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

Bug #1050025 reported by Russell Bryant on 2012-09-12
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Medium
Dolph Mathews
Essex
Medium
Alan Pevec
keystone (Ubuntu)
Undecided
Unassigned
Precise
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.

Related branches

security vulnerability: no → yes
Changed in keystone:
milestone: none → folsom-rc1
Thierry Carrez (ttx) wrote :

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
Thierry Carrez (ttx) wrote :

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
Dolph Mathews (dolph) wrote :

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.

Joseph Heck (heckj) wrote :

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.

Joseph Heck (heckj) wrote :

[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
Joseph Heck (heckj) wrote :

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.

Thierry Carrez (ttx) wrote :

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

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

Changed in keystone:
status: Confirmed → In Progress

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

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
Changed in keystone (Ubuntu):
status: New → Fix Released
Changed in keystone (Ubuntu Precise):
status: New → Confirmed

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

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.

Yolanda Robla (yolanda.robla) wrote :

Test coverage log.

tags: added: verification-done
removed: verification-needed

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.

Launchpad Janitor (janitor) wrote :

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

Changed in keystone (Ubuntu Precise):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers