Bugzilla – Bug 881977
VUL-0: CVE-2014-3476: openstack-keystone: Keystone privilege escalation through trust chained delegation
Last modified: 2014-07-15 08:58:21 UTC
Via distros CRD: 2014-06-12, 1500UTC Date: Mon, 09 Jun 2014 11:17:24 -0400 From: Tristan Cacqueray <tristan.cacqueray@enovance.com> Versions: from 2013.1 to 2013.2.3, and 2014.1 versions up to 2014.1.1 Description: Steven Hardy from Red Hat reported a vulnerability in Keystone chained delegation. By creating a delegation from a trust or OAuth token, a trustee may abuse the identity impersonation against keystone and circumvent the enforced scope, resulting in potential elevated privileges to any of the trustor's projects and or roles. All Keystone deployments configured to enable trusts are affected, which has been the default since Grizzly. Proposed patch: See attached patches. Unless a flaw is discovered in them, these patches will be merged to stable/havana, stable/icehouse and master (Juno development branch) on the public disclosure date. CVE: CVE-2014-3476
Created attachment 593972 [details] Patch for Juno
Created attachment 593973 [details] Patch for havana
Created attachment 593974 [details] Patch for Icehouse
bugbot adjusting priority
An update workflow for this issue was started. This issue was rated as important. Please submit fixed packages until 2014-06-18. When done, reassign the bug to security-team@suse.de. https://swamp.suse.de/webswamp/wf/57789
Affected packages: SLE-11-SP3: openstack-keystone SLE-11-SP3-CLOUD4: openstack-keystone
Issue went public
https://bugs.launchpad.net/keystone/+bug/1324592 https://review.openstack.org/#/q/I1528f9dd003f5e03cbc50b78e1b32dbbf85ffcc2,n,z
Out of the test cases added for fix of 881977, 2 failed because we do not ship oauth1 keystone (see https://review.openstack.org/#/c/29130/): 1) test_oauth_token_cannot_authorize_request_token ERROR ERROR: keystone.tests.test_v3_oauth1.AuthTokenTests.test_oauth_token_cannot_authorize_request_token ---------------------------------------------------------------------- _StringException: Traceback (most recent call last): File "/var/lib/openstack-keystone-test/keystone/tests/test_v3_oauth1.py", line 506, in test_oauth_token_cannot_authorize_request_token url = self._approve_request_token_url() File "/var/lib/openstack-keystone-test/keystone/tests/test_v3_oauth1.py", line 472, in _approve_request_token_url self.consumer = oauth1.Consumer(consumer_id, consumer_secret) AttributeError: 'module' object has no attribute 'Consumer' 2) test_trust_token_cannot_authorize_request_token ERROR ERROR: keystone.tests.test_v3_oauth1.AuthTokenTests.test_trust_token_cannot_authorize_request_token ---------------------------------------------------------------------- _StringException: Traceback (most recent call last): File "/var/lib/openstack-keystone-test/keystone/tests/test_v3_oauth1.py", line 530, in test_trust_token_cannot_authorize_request_token url = self._approve_request_token_url() File "/var/lib/openstack-keystone-test/keystone/tests/test_v3_oauth1.py", line 472, in _approve_request_token_url self.consumer = oauth1.Consumer(consumer_id, consumer_secret) AttributeError: 'module' object has no attribute 'Consumer' https://review.openstack.org/#/c/99700/1/keystone/tests/test_v3_oauth1.py has: from keystone.contrib import oauth1 ... def test_oauth_token_cannot_authorize_request_token(self): 550 self.test_oauth_flow() 551 url = self._approve_request_token_url() 552 body = {'roles': [{'id': self.role_id}]} 553 self.put(url, body=body, token=self.keystone_token_id, 554 expected_status=403) ... def _approve_request_token_url(self): 514 ... self.request_token = oauth1.Token(request_key, request_secret) For cloud 3 we do not ship https://review.openstack.org/#/c/29130/ so the 2 test cases are failing Is this acceptable or we should ship keystone oauth1?
So this is really an issue because of some broken packaging. The fix is (I think) https://build.opensuse.org/request/show/238479 We do not use oauth in SUSE Cloud (afaik), so it might not matter much if that test case is failing. That being said, the security issue itself is not stricly affecting SUSE Cloud either (it's for the v3 API which we don't use), so it might not be that urgent to release it. So I see two approaches: waiting for the packaging fix and re-doing the validation then, or releasing now. I'm fine either way. Security team, what do you think?
I would prefer waiting for the packaging fix. But it's just a hunch since there are no really compelling reasons either way.
Update released for: openstack-keystone, openstack-keystone-doc, openstack-keystone-test, python-keystone Products: SUSE-CLOUD 3.0 (x86_64)
SUSE-SU-2014:0848-1: An update that fixes one vulnerability is now available. Category: security (important) Bug References: 881977 CVE References: CVE-2014-3476 Sources used: SUSE Cloud 3 (src): openstack-keystone-2013.2.4.dev5.g9162837-0.7.1, openstack-keystone-doc-2013.2.4.dev5.g9162837-0.7.1
Reassigning to security team as fix was submitted.