[Openstack-security] [Bug 1435530] Re: keystonemiddleware without TRL checking and default cache config can allow access after token revocation

Doug Chivers 1435530 at bugs.launchpad.net
Wed Sep 2 22:46:47 UTC 2015


** Changed in: ossn
       Status: New => In Progress

** Changed in: ossn
     Assignee: Dave Walker (davewalker) => Doug Chivers (doug-chivers)

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1435530

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

Status in keystonemiddleware:
  New
Status in OpenStack Security Advisory:
  Won't Fix
Status in OpenStack Security Notes:
  In Progress

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystonemiddleware/+bug/1435530/+subscriptions




More information about the Openstack-security mailing list