It was reported [1] that in Keystone V2 token support, by creating a token using the V2 API, a user may evade token revocation. When the token is processed by the V3 API, its "issued_at" time is wrongly updated and then the service will fail to revoke it. Only Keystone setups configured to use revocation events and UUID tokens are affected. CVE request has been sent to oss-security mailing list by upstream [2] Commit that fixes this issue: https://git.openstack.org/cgit/openstack/keystone/commit/?id=a4c73e4382cb062aa9f30fe1960d5014d3c49cc2 [1]: https://bugs.launchpad.net/keystone/+bug/1348820 [2]: http://seclists.org/oss-sec/2014/q3/296
It's stated in the Launchpad ticket that this would only impact Icehouse (openstack-2014.X) since that's where revocation events were added.
Statement: This issue does not affected openstack-keystone as shipped with Red Hat Enterprise Linux OpenStack Platform 4.0.
Keystone in RHEL-OSP-5 (Icehouse) includes this code, although it is marked as experimental in Icehouse upstream, we do include an example of how to enable it in our documentation and thus will need to release an erratum.
IssueDescription: A flaw was found in keystone revocation events that resulted in the "issued_at" time being updated when a token created by the V2 API was processed by the V3 API. This could allow a user to evade token revocation. Only OpenStack Identity setups configured to make use of revocation events and UUID tokens were affected.
This issue has been addressed in following products: OpenStack 5 for RHEL 6 Via RHSA-2014:1122 https://rhn.redhat.com/errata/RHSA-2014-1122.html
This issue has been addressed in following products: OpenStack 5 for RHEL 7 Via RHSA-2014:1121 https://rhn.redhat.com/errata/RHSA-2014-1121.html