[OSSA 2014-006] Trustee token revocations with memcache backend (CVE-2014-2237)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Fix Released
|
Medium
|
Morgan Fainberg | ||
Grizzly |
Fix Released
|
Medium
|
Morgan Fainberg | ||
Havana |
Fix Released
|
Medium
|
Morgan Fainberg | ||
OpenStack Security Advisory |
Fix Released
|
High
|
Tristan Cacqueray |
Bug Description
When using the memcache token backend, In cases where token revocations (bulk revocations) that rely on the trustee's token-index-list to perform the revocations - the revocations cannot occur. This is because trustee tokens are added only to the trustor's token list. This appears to only be an issue for trusts with impersonation enabled. This is most noticeable when the trustee user is disabled or the trustee changes a password. I am sure there are other related scenarios.
Example reproduction -
Create the trust:
curl -H "X-Auth-Token: $TOKEN" -X POST http://
RESPONSE:
{
"trust": {
"id": "0d2dc361043d4f
"links": {
"self": "http://
},
"roles": [
{
},
}
],
"next": null,
"self": "http://
},
}
}
Consume the trust:
vagrant@
{
"auth": {
"identity": {
],
}
},
"scope": {
}
}
}
}
curl -si -d @trust_token.json -H 'Content-Type: application/json' -X POST http://
RESPONSE:
{
"token": {
"id": "0d2dc361043d4f
},
}
},
"catalog": [
... <SNIP FOR BREVITY>
],
"extras": {},
"methods": [
],
"project": {
},
"id": "9b2c18a72c8a47
"name": "admin"
},
"roles": [
{
}
],
"user": {
},
"id": "46c9e36c50c14d
"name": "admin"
}
}
}
Check the memcache token lists, the admin user should have 1 token (used to create the trust), the demo user should have 2 tokens (initial token, and trust token)
ADMIN-ID: 46c9e36c50c14df
DEMO-ID: 36240e5f6ed0485
vagrant@
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
get usertokens-
VALUE usertokens-
"1bb6a8abc42e1d
END
get usertokens-
VALUE usertokens-
"36df008ec5b5d3
This does not affect the SQL or KVS backends. This will affect Master (until KVS refactor is complete), Havana, and Grizzly. The reason for this occurring is a lack of testing against the memcache backend itself (and it’s logic). With the refactor of KVS (keyvaluestore) it will ensure the testing is the same against all KVS (memcache, in-memory, redis, etc) backends since the interfaces work in the same manner/mechanism.
The root of this issue stems from the old KVS and SQL systems being less strict on matching trust scoped tokens:
(KVS) http://
(SQL) http://
Whereas memcache needs to use the user-index to determine tokens for a given user before matching against the trust scope:
http://
CVE References
description: | updated |
Changed in ossa: | |
status: | Confirmed → Triaged |
Changed in keystone: | |
milestone: | none → icehouse-3 |
summary: |
- Trustee token revocations with memcache backend + Trustee token revocations with memcache backend (CVE-2014-2237) |
Changed in ossa: | |
status: | Triaged → Fix Committed |
Changed in keystone: | |
status: | Fix Committed → Fix Released |
summary: |
- Trustee token revocations with memcache backend (CVE-2014-2237) + [OSSA 2014-006] Trustee token revocations with memcache backend + (CVE-2014-2237) |
Changed in keystone: | |
milestone: | icehouse-3 → 2014.1 |
Sounds legit... Could anyone else in Keystone confirm ?