keystonemiddleware without TRL checking and default cache config can allow access after token revocation

Bug #1435530 reported by Morgan Fainberg on 2015-03-23
46
This bug affects 5 people
Affects Status Importance Assigned to Milestone
OpenStack Security Advisory
Undecided
Unassigned
OpenStack Security Notes
Undecided
Doug Chivers
keystonemiddleware
Low
Unassigned

Bug Description

*** This can probably be made public right away, but I am erring on the side of caution and letting the VMT make this call ***

Yukihiro KAWADA reported an issue with Keystone that indirectly led/confirmed an issue with Keystonemiddleware when the Token Revocation List (TRL) is not utilized and caching is enabled (default). If the TRL is not used (common with UUID tokens, as PKI signing is not setup), a token that is used on an endpoint is valid for 300s (default, may be more/less based on config) even if the token is revoked within keystone (this include disabling of the user).

Worse, the default is is to cache the tokens in-process memory, which means that the token may appear to be revoked/invalid in some cases and then become re-valid on subsequent requests unless a shared cache is used.

This appears to be insane default(s) that lead to a window of exposure that is not clearly communicated either with defaults or when caching times are adjusted.

Grant Murphy (gmurphy) wrote :

I agree it looks like it could be dup.

Anyway I still added the OSSA task to this bug and marked it incomplete pending a discussion with VMT on how to handle.

I couldn't find where the OSSG published a OSSN for bug 1287301 so it might be worth doing this time around if it was missed last time.

Changed in ossa:
status: New → Incomplete
Thierry Carrez (ttx) wrote :

If I understand correctly the worse case scenario here is a slightly deferred token invalidation, which I would not consider OSSA (advisory) material (could be considered "working as designed"). It is certainly OSSN (security note / documentation) material though.

Given the impact and in order to facilitate work on this, I propose we open this bug publicly.

Morgan Fainberg (mdrnstm) wrote :

100% spot on Thierry. And I agree we open this to the public. I deferred that choice to the VMT though.

Brant, bug 1287301 affects keystone setups with a TRL while this one affects setups without TRL... Though the behavior is basically the same.

+1 to open this and remove the OSSA task.

Thierry Carrez (ttx) wrote :

OK, it's public now.

information type: Private Security → Public
Changed in ossa:
status: Incomplete → Won't Fix
Dolph Mathews (dolph) wrote :

This is by design, but we have a chance to improve the behavior with token revocation events.

Morgan Fainberg (mdrnstm) wrote :

This is a case where an OSSN and eliminating awful defaults will make behavior less bad. The fact that a similar issue in the past did not have an OSSN was the main reason this was raised as it was.

Robert Clark (robert-clark) wrote :

I agree that an OSSN would be appropriate.

Dave Walker (davewalker) on 2015-07-08
Changed in ossn:
assignee: nobody → Dave Walker (davewalker)
Changed in ossn:
status: New → In Progress
assignee: Dave Walker (davewalker) → Doug Chivers (doug-chivers)
Nathan Kinder (nkinder) wrote :

This has been published as OSSN-0056:

  https://wiki.openstack.org/wiki/OSSN/OSSN-0056

Changed in ossn:
status: In Progress → Fix Released
Changed in keystonemiddleware:
status: New → Triaged
importance: Undecided → Low
Morgan Fainberg (mdrnstm) wrote :

This is relatively by design. See previous comments.

Changed in keystonemiddleware:
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers