[OSSA 2012-010] Once a token is created/distributed its expiry date can be circumvented
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Fix Released
|
Medium
|
Derek Higgins | ||
Essex |
Fix Released
|
Undecided
|
Unassigned | ||
OpenStack Security Advisory |
Fix Released
|
Undecided
|
Thierry Carrez |
Bug Description
When a token is distributed that is intended to expire, this expiry time
can be worked around by continuesly creating new tokens before the old one has
expired.
Effectively granting the holder of the token open ended access to a service.
For example (with expiration = 60 seconds)
# Create a token with username/password
> date -u ; ./tools/
Fri May 11 17:43:00 UTC 2012
+------
| Property | Value |
+------
| expires | 2012-05-
| id | 6345d6fd276f4eb
| tenant_id | b0b68a8de4d141d
| user_id | e20d930d58c44b1
+------
# Before this token expires create another
> date -u ; curl -X POST http://
Fri May 11 17:43:50 UTC 2012
{"access": {"token": {"expires": "2012-05-
# Continue this process as much as you want
> date -u ; curl -X POST http://
Fri May 11 17:44:41 UTC 2012
{"access": {"token": {"expires": "2012-05-
# The original token has now expired
> date -u ; curl -X POST http://
Fri May 11 17:44:50 UTC 2012
{"error": {"message": "The request you have made requires authentication.", "code": 401, "title": "Not Authorized"}} >
# but I still have access to the system
> date -u ; curl -X POST http://
Fri May 11 17:45:01 UTC 2012
{"access": {"token": {"expires": "2012-05-
To prevent this either
1) the code could be removed that allows tokens to be created from other tokens
or
2) a small change to carry over the expiration time between tokens could be added (retaining some compatibility with clients that use this functionality)
CVE References
tags: | added: essex-backport |
Changed in keystone: | |
milestone: | none → folsom-2 |
status: | Fix Committed → Fix Released |
Changed in keystone: | |
milestone: | folsom-2 → 2012.2 |
summary: |
- Once a token is created/distributed its expiry date can be circumvented + [OSSA 2012-010] Once a token is created/distributed its expiry date can + be circumvented |
Changed in ossa: | |
assignee: | nobody → Thierry Carrez (ttx) |
status: | New → Fix Released |
I agree that this is a problem. Tokens timeout to limit the scope of abuse through compromise/loss. Allowing tokens to be extended or chained in this way does water down the protection somewhat but I don't think it's a big problem.
I could be wrong but I'd expect that the initial attack vector for this is to obtain a token and extend it before it expires. At that point an attacker could do any number of things to attack or modify this users settings via the API, perhaps having the same effect.
I'd like to understand where the requirement for chaining tokens like this came from before we take steps to limit/remove it as I expect doing so could break some applications that may rely on it currently.