[OSSA 2012-010] Following a password compromise and subsequent password change, tokens remain valid.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Fix Released
|
High
|
Derek Higgins | ||
Essex |
Fix Released
|
Undecided
|
Alan Pevec | ||
OpenStack Security Advisory |
Fix Released
|
Undecided
|
Thierry Carrez | ||
keystone (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Precise |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
If a password is comprimised and a user changes their password(or has it changed),
tokens that were issued previous to the password change remain valid. This
not only allows an attacker to keep access to the account for the lifetime of the
token but they can also create new tokens before the origional token is expired
allowing them to hold onto access indefinatly.
Of course knowing this an administrator could DELETE tokens individually via the API if
they knew the id of each one.
To reproduce :
Create an user test user (in this case id = ebae56e4d2114b9
# get a token
curl -X POST http://
{"access": {"token": {"expires": "2012-05-
# change password because of a compromise
keystone user-password-
# try to get a token with old credentials
curl -X POST http://
{"error": {"message": "Invalid user / password", "code": 401, "title": "Not Authorized"}}
# but we still have an old token that can be used with endpoints
curl -X POST http://
{"access": {"token": {"expires": "2012-05-
# disabling the user doesn't prevent the token from working either, it only appears to disable password authentication
# NOTE : this should probably be a seperate issue i.e. disabling a user doesn't disable/delete tokens
curl -X POST http://
{"access": {"token": {"expires": "2012-05-
# disable the user
keystone user-update --enabled false ebae56e4d2114b9
# confirm
curl -X POST http://
{"error": {"message": "User has been disabled", "code": 403, "title": "Not Authorized"}}
# a token can still be used
curl -X POST http://
{"access": {"token": {"expires": "2012-05-
Related branches
- Ubuntu Server Developers: Pending requested
-
Diff: 13 lines (+6/-0)1 file modifieddebian/changelog (+6/-0)
CVE References
Changed in keystone: | |
milestone: | none → folsom-1 |
Changed in keystone: | |
status: | Fix Committed → Fix Released |
tags: | added: essex-backport |
Changed in keystone (Ubuntu): | |
status: | New → Fix Released |
Changed in keystone (Ubuntu Precise): | |
status: | New → Confirmed |
Changed in keystone: | |
milestone: | folsom-1 → 2012.2 |
summary: |
- Following a password compromise and subsequent password change, tokens - remain valid. + [OSSA 2012-010] Following a password compromise and subsequent password + change, tokens remain valid. |
Changed in ossa: | |
assignee: | nobody → Thierry Carrez (ttx) |
status: | New → Fix Released |
Thanks for the report, Derek. I went ahead and added the Keystone PTL.
Regarding the security status of this bug, I'm leaning toward treating this as a 'security hardening' issue as opposed to a vulnerability. That basically means that we acknowledge that this issue has important security related implications, but we won't put it under embargo and treat it with the vulnerability process. Instead, we'll work on this in the open like other bugs.
So, the suggestion here is that tokens should be automatically invalidated when a password gets changed?