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 |
|
|
|