OpenStack Identity (Keystone)

[OSSA 2012-016]Token authentication for a user in a disabled tenant does not raise Unauthorized error

Reported by Rohit Karajgi on 2012-04-26
256
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Keystone
Medium
Dolph Mathews
Essex
Medium
Unassigned
OpenStack Security Advisory
Undecided
Russell Bryant
keystone (Ubuntu)
Undecided
Unassigned
Precise
Undecided
Unassigned

Bug Description

Scenario: Token authentication for a user belonging to a disable tenant should not be allowed.

Steps:
1. Create a tenant and a user for the tenant
2. Disable the tenant
3. Request token authentication (POST) for the user and tenant
Eg: {
         "auth": {
                  "tenantName": "disabled_tenant",
                  "passwordCredentials": {
                                                  "username": "test_user1",
                                                  "password": "password"
                     }
          }
    }

Expected Status: HTTP 401 Unauthorized
Actual Status: HTTP 200 OK

Dolph Mathews (dolph) on 2012-05-01
Changed in keystone:
assignee: nobody → Dolph Mathews (dolph)
Joseph Heck (heckj) wrote :

Should it?

Since a user isn't determined to be uniquely part of a tenant (i.e. a user *can* be associated with multiple tenants), then the authentication of a user is a completely independent of it's applicability to the tenant and it's state (enabled/disabled).

There is the potential for a special case that *when* a user is associated with a single tenant, and that tenant is disabled, the auth should fail. Is that what you're suggesting?

Changed in keystone:
status: New → Incomplete
Rohit Karajgi (rohitk) wrote :

Hi Joseph,

Why should an auth request for a user against a disabled tenant be successful in any case?
In the auth request, we do pass the tenant name, and if that tenant is disabled, the auth should be denied.

So, essentially I feel the HTTP response code should be sent accordingly.

Changed in keystone:
status: Incomplete → Opinion
Jay Pipes (jaypipes) wrote :

Joseph, I think you need to re-read the bug report... Rohit is showing that when a user is authenticating **as a specific tenant that has been disabled** that the user is being authenticated, when the user should not be authenticated.

Joseph Heck (heckj) wrote :

agreed if the auth (as rohit defines) is explicit to a tenant that is disabled, then it should be unauthorized. if the auth is just user+password, relying on a default tenant choice, then its more unclear.

Changed in keystone:
status: Opinion → Triaged
importance: Undecided → Medium

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

Changed in keystone:
status: Triaged → In Progress

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

commit 4ebfdfaf23c6da8e3c182bf3ec2cb2b7132ef685
Author: Dolph Mathews <email address hidden>
Date: Mon Jul 16 16:08:32 2012 -0500

    Raise unauthorized if tenant disabled (bug 988920)

    If the client attempts to explicitly authenticate against a disabled
    tenant, keystone should return HTTP 401 Unauthorized.

    Change-Id: I49fe56b6ef8d9f2fc6b9357472dae8964bb9cb9c

Changed in keystone:
status: In Progress → Fix Committed
Alan Pevec (apevec) on 2012-07-30
tags: added: essex-backport

Reviewed: https://review.openstack.org/10534
Committed: http://github.com/openstack/keystone/commit/5373601bbdda10f879c08af1698852142b75f8d5
Submitter: Jenkins
Branch: stable/essex

commit 5373601bbdda10f879c08af1698852142b75f8d5
Author: Dolph Mathews <email address hidden>
Date: Mon Jul 16 16:08:32 2012 -0500

    Raise unauthorized if tenant disabled (bug 988920)

    If the client attempts to explicitly authenticate against a disabled
    tenant, keystone should return HTTP 401 Unauthorized.

    Change-Id: I49fe56b6ef8d9f2fc6b9357472dae8964bb9cb9c

tags: added: in-stable-essex
Thierry Carrez (ttx) on 2012-08-16
Changed in keystone:
milestone: none → folsom-3
status: Fix Committed → Fix Released
Dave Walker (davewalker) on 2012-08-24
Changed in keystone (Ubuntu):
status: New → Fix Released
Changed in keystone (Ubuntu Precise):
status: New → Confirmed

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/9862
Stable review: https://review.openstack.org/10534

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

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.

This bug was fixed in the package keystone - 2012.1+stable~20120824-a16a0ab9-0ubuntu2

---------------
keystone (2012.1+stable~20120824-a16a0ab9-0ubuntu2) precise-proposed; urgency=low

  * New upstream release (LP: #1041120):
    - debian/patches/0013-Flush-tenant-membership-deletion-before-user.patch:
      Dropped.
  * Resynchronize with stable/essex:
    - authenticate in ldap backend doesn't return a list of roles
      (LP: #1035428)
    - LDAP should not check username on "sn" field (LP: #997700)
    - Admin API doesn't valid token. (LP: #1006815, #1006822)
    - Memcache token backend eventually stops working. (LP: #1012381)
    - EC2 credentials not migrated from legacy (diablo) database. (LP: #1016056)
    - Deleting tenants or users does not cleanup metadata. (LP: #973243)
    - Deleting tenants does not cleanup its user associations. (LP: #974199)
    - TokenNotFound not raised in testsuite beacuse of timezone issues. (LP: #983800)
    - Token authentication for a user in a disabled tenant does not raise
      Unauthorized error. (LP: #988920)
    - export_legacy_catalog doesn't convert url names correctly. (LP: #994936)
    - Following a password compromise and subsequent password change,
      tokens remain valid. (LP: #996595)
    - Tokens remain valid after a user account is disabled. (LP: #997194)
 -- Adam Gandelman <email address hidden> Fri, 24 Aug 2012 03:34:59 -0400

Changed in keystone (Ubuntu Precise):
status: Confirmed → Fix Released
Russell Bryant (russellb) wrote :

Can a keystone dev comment on the potential security impact of this bug? I'm trying to figure out if we need to go back and issue a security advisory for this. Would this token be successfully validated allowing a user to do stuff with the token they shouldn't have received?

security vulnerability: no → yes
Thierry Carrez (ttx) on 2012-09-27
Changed in keystone:
milestone: folsom-3 → 2012.2
Dolph Mathews (dolph) wrote :

Russell: It's exactly as you describe.

In this case, authentication succeeds as expected, but authorization should fail (disabling the tenant should break the user-tenant authorization relationship).

Once the token is established with authorization on the tenant, keystone would respond 200 OK to token validation requests from other OpenStack services, allowing the user to work with the tenant's resources -- probably not what the admin had in mind when disabling the tenant!

Russell Bryant (russellb) wrote :

Please review this vulnerability description. Once confirmed, it will go out in an OSSA.

Title: Token authorization for a user in a disabled tenant is allowed
Impact: High
Reporter: Rohit Karajgi (NTT Data)
Affects: Essex (prior to 2012.1.2), Folsom (prior to folsom-3 development milestone)

Description:
Rohit Karajgi reported a vulnerability in Keystone. It was possible to get a token that is authorized for a disabled tenant. Once the token is established with authorization on the tenant, keystone would respond 200 OK to token validation requests from other OpenStack services, allowing the user to work with the tenant's resources.

Joseph Heck (heckj) wrote :

Good description, ack.

Thierry Carrez (ttx) wrote :

Description looks good. Maybe add that the fix already shipped in 2012.1.2 and 2012.2.

Thierry Carrez (ttx) on 2013-06-07
summary: - Token authentication for a user in a disabled tenant does not raise
- Unauthorized error
+ [OSSA 2012-016]Token authentication for a user in a disabled tenant does
+ not raise Unauthorized error
Changed in ossa:
assignee: nobody → Russell Bryant (russellb)
status: New → Fix Released
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers