yahoo-eng-team team mailing list archive

[Rahul U Nair <rahulunair@xxxxxxxxx>]

** Changed in: ossn
     Assignee: Rahul U Nair (rahulunair) => (unassigned)

** Changed in: ossn
     Assignee: (unassigned) => Luke Hinds (lhinds)

** Changed in: ossn
       Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1553324

Title:
  potential DOS with revoke by id or audit_id

Status in OpenStack Identity (keystone):
  New
Status in OpenStack Security Advisory:
  Won't Fix
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  With our default policy, token revocation can be self-served. Without
  any rate limiting or SIEM mechanism in place, any user can potentially
  flood the revocation_event table to cause significant performance
  degradation or worst DOS. I've attached a simple script to
  continuously revoking one's own token and time the token validation
  time. On a vanilla devstack, with dogpile cache enabled, token
  validation time go from roughly 40ms to over 300ms with about 2K
  revocation events.

  We don't cleanup the revocation events till token expiration plus
  expiration_buffer, which is 30 minutes by default. With the default
  token TTL of 3600 seconds, a user could potentially fill up at least a
  few thousand events during that time.

  I know this may sound like a broken record, and yes, rate limiting or
  SIEM should be used. Perhaps we can add this to security hardening or
  OSSN?

  In the long run, I think we need to rethink how we handle revoke by ID
  as self-service. Now that we have shadow user accounts, maybe we can
  implement something to suspend that user if we detect token revocation
  abuse?

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