← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1260080] Re: [OSSA 2014-006] Trustee token revocations with memcache backend (CVE-2014-2237)

 

** Changed in: keystone/grizzly
       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:
  [OSSA 2014-006] Trustee token revocations with memcache backend
  (CVE-2014-2237)

Status in OpenStack Identity (Keystone):
  Fix Released
Status in Keystone grizzly series:
  Fix Released
Status in Keystone havana series:
  Fix Committed
Status in OpenStack Security Advisories:
  Fix Released

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