| 2016-03-04 19:01:39 |
Guang Yee |
bug |
|
|
added bug |
| 2016-03-04 19:01:39 |
Guang Yee |
attachment added |
|
script to revoke token and time token validation https://bugs.launchpad.net/bugs/1553324/+attachment/4588557/+files/revoke_test.sh |
|
| 2016-03-04 19:17:52 |
Tristan Cacqueray |
bug task added |
|
ossa |
|
| 2016-03-04 19:19:03 |
Tristan Cacqueray |
ossa: status |
New |
Incomplete |
|
| 2016-03-04 19:19:38 |
Tristan Cacqueray |
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? |
This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added to the bug as attachments.
--
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? |
|
| 2016-03-04 19:19:51 |
Tristan Cacqueray |
bug |
|
|
added subscriber Keystone Core security contacts |
| 2016-03-07 15:15:29 |
Tristan Cacqueray |
bug |
|
|
added subscriber OSSG CoreSec |
| 2016-03-29 20:14:10 |
Travis McPeak |
bug task added |
|
ossn |
|
| 2016-04-11 14:51:14 |
Tristan Cacqueray |
description |
This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added to the bug as attachments.
--
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? |
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? |
|
| 2016-04-11 14:52:09 |
Tristan Cacqueray |
information type |
Private Security |
Public |
|
| 2016-04-28 18:16:48 |
Luke Hinds |
ossn: assignee |
|
Luke Hinds (lhinds) |
|
| 2016-04-30 21:37:23 |
Tristan Cacqueray |
ossa: status |
Incomplete |
Won't Fix |
|
| 2016-07-26 14:35:56 |
Kundai Andrew Midzi |
bug |
|
|
added subscriber Kundai Andrew Midzi |
| 2016-08-17 19:16:53 |
Rahul U Nair |
ossn: assignee |
Luke Hinds (lhinds) |
Rahul U Nair (rahulunair) |
|
| 2016-08-17 19:26:53 |
Rahul U Nair |
ossn: status |
New |
Confirmed |
|
| 2016-08-17 19:36:54 |
Rahul U Nair |
ossn: assignee |
Rahul U Nair (rahulunair) |
|
|
| 2016-08-17 19:37:20 |
Rahul U Nair |
ossn: assignee |
|
Luke Hinds (lhinds) |
|
| 2016-08-17 19:37:32 |
Rahul U Nair |
ossn: status |
Confirmed |
Fix Released |
|
| 2016-11-15 16:32:06 |
Steve Martinelli |
keystone: status |
New |
Fix Released |
|
