potential DOS with revoke by id or audit_id
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Fix Released
|
Undecided
|
Unassigned | ||
OpenStack Security Advisory |
Won't Fix
|
Undecided
|
Unassigned | ||
OpenStack Security Notes |
Fix Released
|
Undecided
|
Luke Hinds |
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?
Changed in ossn: | |
assignee: | nobody → Luke Hinds (lhinds) |
Changed in ossa: | |
status: | Incomplete → Won't Fix |
Changed in ossn: | |
assignee: | Luke Hinds (lhinds) → Rahul U Nair (rahulunair) |
Changed in ossn: | |
status: | New → Confirmed |
Changed in ossn: | |
assignee: | Rahul U Nair (rahulunair) → nobody |
assignee: | nobody → Luke Hinds (lhinds) |
status: | Confirmed → Fix Released |
Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.