yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #10968
[Bug 1260080] Re: Trustee token revocations with memcache backend (CVE-2014-2237)
** Changed in: keystone
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1260080
Title:
Trustee token revocations with memcache backend (CVE-2014-2237)
Status in OpenStack Identity (Keystone):
Fix Released
Status in Keystone grizzly series:
In Progress
Status in Keystone havana series:
In Progress
Status in OpenStack Security Advisories:
Fix Committed
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://127.0.0.1:35357/v3/OS-
TRUST/trusts -d '{"trust":{"impersonation": true, "project_id":
"9b2c18a72c8a477b891b48931c26cebe", "roles":
[{"name":"admin"}],"trustee_user_id":"36240e5f6ed04857bf15d08a519b6e37","trustor_user_id":"46c9e36c50c14dfab36b6511d6ebedd4"}}'
-H 'Content-Type: application/json'
RESPONSE:
{
"trust": {
"expires_at": null,
"id": "0d2dc361043d4f9d8a84a7f253e20924",
"impersonation": true,
"links": {
"self": "http://172.16.30.195:5000/v3/OS-TRUST/trusts/0d2dc361043d4f9d8a84a7f253e20924"
},
"project_id": "9b2c18a72c8a477b891b48931c26cebe",
"roles": [
{
"id": "0bd1d61badd742bebc044dc246a43513",
"links": {
"self": "http://172.16.30.195:5000/v3/roles/0bd1d61badd742bebc044dc246a43513"
},
"name": "admin"
}
],
"roles_links": {
"next": null,
"previous": null,
"self": "http://172.16.30.195:5000/v3/OS-TRUST/trusts/0d2dc361043d4f9d8a84a7f253e20924/roles"
},
"trustee_user_id": "36240e5f6ed04857bf15d08a519b6e37",
"trustor_user_id": "46c9e36c50c14dfab36b6511d6ebedd4"
}
}
Consume the trust:
vagrant@precise64:~/devstack$ cat trust_token.json
{
"auth": {
"identity": {
"methods": [
"token"
],
"token": {
"id": "<PKI TOKEN ID>"
}
},
"scope": {
"OS-TRUST:trust": {
"id": "0d2dc361043d4f9d8a84a7f253e20924"
}
}
}
}
curl -si -d @trust_token.json -H 'Content-Type: application/json' -X
POST http://localhost:35357/v3/auth/tokens
RESPONSE:
{
"token": {
"OS-TRUST:trust": {
"id": "0d2dc361043d4f9d8a84a7f253e20924",
"impersonation": true,
"trustee_user": {
"id": "36240e5f6ed04857bf15d08a519b6e37"
},
"trustor_user": {
"id": "46c9e36c50c14dfab36b6511d6ebedd4"
}
},
"catalog": [
... <SNIP FOR BREVITY>
],
"expires_at": "2013-12-12T20:06:00.239812Z",
"extras": {},
"issued_at": "2013-12-11T20:10:22.224381Z",
"methods": [
"token",
"password"
],
"project": {
"domain": {
"id": "default",
"name": "Default"
},
"id": "9b2c18a72c8a477b891b48931c26cebe",
"name": "admin"
},
"roles": [
{
"id": "0bd1d61badd742bebc044dc246a43513",
"name": "admin"
}
],
"user": {
"domain": {
"id": "default",
"name": "Default"
},
"id": "46c9e36c50c14dfab36b6511d6ebedd4",
"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: 46c9e36c50c14dfab36b6511d6ebedd4
DEMO-ID: 36240e5f6ed04857bf15d08a519b6e37
vagrant@precise64:~/devstack$ telnet localhost 11211
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
get usertokens-46c9e36c50c14dfab36b6511d6ebedd4
VALUE usertokens-46c9e36c50c14dfab36b6511d6ebedd4 0 104
"1bb6a8abc42e1d1a944e08a20de20a91","ee512379a66027733001648799083349"
END
get usertokens-36240e5f6ed04857bf15d08a519b6e37
VALUE usertokens-36240e5f6ed04857bf15d08a519b6e37 0 34
"36df008ec5b5d3dd6983c8fe84d407f6"
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://git.openstack.org/cgit/openstack/keystone/tree/keystone/token/backends/kvs.py?id=cc0c6565e3fe6ed60543e6ebd5e54cba51e59fc6#n86
(SQL) http://git.openstack.org/cgit/openstack/keystone/tree/keystone/token/backends/sql.py?id=cc0c6565e3fe6ed60543e6ebd5e54cba51e59fc6#n126
Whereas memcache needs to use the user-index to determine tokens for a given user before matching against the trust scope:
http://git.openstack.org/cgit/openstack/keystone/tree/keystone/token/backends/memcache.py?id=cc0c6565e3fe6ed60543e6ebd5e54cba51e59fc6#n190
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1260080/+subscriptions