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

Morgan Fainberg morgan.fainberg at gmail.com
Wed Oct 24 18:30:50 UTC 2018


This is relatively by design. See previous comments.

** Changed in: keystonemiddleware
       Status: Triaged => Won't Fix

-- 
You received this bug notification because you are a member of OpenStack
Security SIG, 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:
  Won't Fix
Status in OpenStack Security Advisory:
  Won't Fix
Status in OpenStack Security Notes:
  Fix Released

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