Activity log for bug #1129713

Date Who What changed Old value New value Message
2013-02-19 02:58:43 Adam Young bug added bug
2013-02-19 02:58:43 Adam Young attachment added validate-from-backend-folsom-20130218.patch https://bugs.launchpad.net/bugs/1129713/+attachment/3535725/+files/validate-from-backend-folsom-20130218.patch
2013-02-19 02:59:19 Adam Young attachment added patch for grizzly https://bugs.launchpad.net/keystone/+bug/1129713/+attachment/3535726/+files/validate-from-backend-grizzly-20130218.patch
2013-02-19 03:00:19 Adam Young bug added subscriber Guang Yee
2013-02-19 03:01:11 Adam Young description for PKI tokens, we are bypassing token.get_token() call and therefore skipping the “valid=True” check. In Grizzly, this code is in keystone/token/controllers.py In Folsom, this code is in keystone/service.py The if block bypasses the backend check. It is in the backend where tokens are checked for revocation. def _get_token_ref(self, context, token_id, belongs_to=None): """Returns a token if a valid one exists. Optionally, limited to a token owned by a specific tenant. """ # TODO(termie): this stuff should probably be moved to middleware self.assert_admin(context) if cms.is_ans1_token(token_id): data = json.loads(cms.cms_verify(cms.token_to_cms(token_id), CONF.signing.certfile, CONF.signing.ca_certs)) data['access']['token']['user'] = data['access']['user'] data['access']['token']['metadata'] = data['access']['metadata'] if belongs_to: assert data['access']['token']['tenant']['id'] == belongs_to token_ref = data['access']['token'] else: token_ref = self.token_api.get_token(context=context, token_id=token_id) return token_ref The exposure is limited to people that are passing the whole PKI token back for validation via the web service. This PKI tokens were supposed to be validated primarily via Crypto, but there is an option to validate them against the live server as well. It is only this last code path that is affected. It is unlikely to be triggered in Folsom, as people have to make a deliberate decision to use PKI tokens, and are unlikely to be validating them against the Keystone server. Remote services can choose to pass a Hash of the PKI token to the validate Web API, which web services are likely to do, as the Hash is short enough to fit in a cookie. The Hash is then it looked up using the backend get_token() behavior and works correctly. It does not effect the keystone calls that first require validating the token. For example if a user runs tenant_list against their own account, using a PKI token, they do token_ref = self.token_api.get_token(context=context, token_id=context['token_id']) This was discovered by Guang Yee. for PKI tokens, we are bypassing token.get_token() call and therefore skipping the “valid=True” check. In Grizzly, this code is in keystone/token/controllers.py In Folsom, this code is in keystone/service.py The if block bypasses the backend check. It is in the backend where tokens are checked for revocation. def _get_token_ref(self, context, token_id, belongs_to=None):         """Returns a token if a valid one exists. Optionally, limited to a token owned by a specific tenant. """         # TODO(termie): this stuff should probably be moved to middleware         self.assert_admin(context)         if cms.is_ans1_token(token_id):             data = json.loads(cms.cms_verify(cms.token_to_cms(token_id),                                              CONF.signing.certfile,                                              CONF.signing.ca_certs))             data['access']['token']['user'] = data['access']['user']             data['access']['token']['metadata'] = data['access']['metadata']             if belongs_to:                 assert data['access']['token']['tenant']['id'] == belongs_to             token_ref = data['access']['token']         else:             token_ref = self.token_api.get_token(context=context,                                                  token_id=token_id)         return token_ref The exposure is limited to people that are passing the whole PKI token back for validation via the web service. This PKI tokens were supposed to be validated primarily via Crypto, but there is an option to validate them against the live server as well. It is only this last code path that is affected. It is unlikely to be triggered in Folsom, as people have to make a deliberate decision to use PKI tokens, and are unlikely to be validating them against the Keystone server. Remote services can choose to pass a Hash of the PKI token to the validate Web API, which web services are likely to do, as the Hash is short enough to fit in a cookie. The Hash is then it looked up using the backend get_token() behavior and works correctly.  It does not effect the keystone calls that first require validating the token. For example if a user runs tenant_list against their own account, using a PKI token, they do  token_ref = self.token_api.get_token(context=context,                                       token_id=context['token_id']) This was discovered by Guang Yee.
2013-02-19 10:09:41 Thierry Carrez bug added subscriber Keystone Core Developers
2013-02-19 10:16:05 Thierry Carrez keystone: importance Undecided Medium
2013-02-19 10:16:05 Thierry Carrez keystone: status New Confirmed
2013-02-19 10:16:16 Thierry Carrez bug added subscriber OpenStack Vulnerability Management team
2013-02-20 05:06:03 Adam Young attachment added validate-from-backend-folsom-20130218-2.patch https://bugs.launchpad.net/keystone/+bug/1129713/+attachment/3537580/+files/validate-from-backend-folsom-20130218-2.patch
2013-02-20 05:06:28 Adam Young attachment added validate-from-backend-grizzly-20130218-2.patch https://bugs.launchpad.net/keystone/+bug/1129713/+attachment/3537581/+files/validate-from-backend-grizzly-20130218-2.patch
2013-03-06 17:57:29 Adam Young attachment added validate-from-backend-folsom-20130306.patch https://bugs.launchpad.net/keystone/+bug/1129713/+attachment/3560812/+files/validate-from-backend-folsom-20130306.patch
2013-03-07 16:08:54 Thierry Carrez nominated for series keystone/folsom
2013-03-07 16:08:54 Thierry Carrez bug task added keystone/folsom
2013-03-07 16:09:18 Thierry Carrez keystone/folsom: status New Triaged
2013-03-07 16:09:20 Thierry Carrez keystone/folsom: importance Undecided Medium
2013-03-07 16:09:28 Thierry Carrez keystone: status Confirmed Invalid
2013-03-11 10:35:20 Thierry Carrez keystone/folsom: status Triaged Confirmed
2013-03-14 17:22:00 Dolph Mathews attachment added validate-from-backend-folsom-20130306-v2.patch https://bugs.launchpad.net/keystone/folsom/+bug/1129713/+attachment/3574384/+files/validate-from-backend-folsom-20130306-v2.patch
2013-03-15 09:45:10 Thierry Carrez keystone/folsom: status Confirmed Triaged
2013-03-18 10:15:52 Thierry Carrez cve linked 2013-1865
2013-03-20 11:32:37 Thierry Carrez bug added subscriber Canonical Security Team
2013-03-20 11:32:47 Thierry Carrez bug added subscriber OpenStack Stable Branch Maintainers
2013-03-20 15:01:05 Thierry Carrez information type Private Security Public Security
2013-03-20 15:01:42 OpenStack Infra keystone/folsom: status Triaged In Progress
2013-03-20 15:01:42 OpenStack Infra keystone/folsom: assignee Dolph Mathews (dolph)
2013-03-20 15:33:55 OpenStack Infra keystone/folsom: status In Progress Fix Committed
2013-03-20 15:43:42 Thierry Carrez bug added subscriber Thierry Carrez
2013-03-20 15:43:44 Thierry Carrez removed subscriber OpenStack Vulnerability Management team
2013-03-20 21:12:45 Launchpad Janitor branch linked lp:ubuntu/quantal-security/keystone
2013-03-22 13:32:27 Launchpad Janitor branch linked lp:~james-page/keystone/folsom-resync
2013-03-22 14:12:38 Launchpad Janitor branch linked lp:~openstack-ubuntu-testing/keystone/folsom
2013-03-27 15:04:29 Alan Pevec keystone/folsom: milestone 2012.2.4
2013-04-11 19:21:38 Alan Pevec keystone/folsom: status Fix Committed Fix Released
2013-05-24 12:50:00 Thierry Carrez summary Validation of PKI tokens bypasses revocation check [OSSA 2013-009] Validation of PKI tokens bypasses revocation check
2013-05-24 12:50:11 Thierry Carrez bug task added ossa
2013-05-24 12:50:21 Thierry Carrez ossa: status New Fix Released
2013-05-24 12:50:21 Thierry Carrez ossa: assignee Thierry Carrez (ttx)
2013-12-16 14:09:02 Curtis Hovey removed subscriber Registry Administrators