Bug 843443 - (CVE-2013-4222) VUL-0: CVE-2013-4222: openstack-keystone: incorrect user token revocation
(CVE-2013-4222)
VUL-0: CVE-2013-4222: openstack-keystone: incorrect user token revocation
Status: RESOLVED FIXED
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
unspecified
Other Other
: P3 - Medium : Normal
: ---
Assigned To: Security Team bot
Security Team bot
maint:released:sle11-sp3:55534
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-01 08:51 UTC by Marcus Meissner
Modified: 2014-03-24 08:33 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Meissner 2013-10-01 08:51:07 UTC
is public via cve db

CVE-2013-4222

OpenStack Identity (Keystone) Folsom, Grizzly 2013.1.3 and earlier, and Havana before havana-3 does not properly revoke user tokens when a tenant is disabled, which allows remote authentica
ted users to retain access via the token.



Reference: CONFIRM: https://bugs.launchpad.net/ossn/+bug/1179955
Reference: FEDORA: http://lists.fedoraproject.org/pipermail/package-announce/2013-September/116489.html
Comment 1 Vincent Untz 2013-10-01 09:45:29 UTC
Hrm, actually, I think the fix is already part of the update currently in the hands of maintenance QA.

Security team: how do you want to deal with that? Just let the current update be processed? Do you want to have the CVE mentioned in .changes?
Comment 2 Swamp Workflow Management 2013-10-01 22:00:28 UTC
bugbot adjusting priority
Comment 3 Sascha Peilicke 2013-10-02 11:58:42 UTC
(In reply to comment #1)
> Hrm, actually, I think the fix is already part of the update currently in the
> hands of maintenance QA.

Confirmed, fix is in SP3:Update:Test ATM.

> Security team: how do you want to deal with that? Just let the current update
> be processed? Do you want to have the CVE mentioned in .changes?

Since I was touching it anyway, I just added bnc/cve numbers to the changes file in D:C:2.0:Staging. This or next update...
Comment 4 Marcus Meissner 2013-10-02 14:24:11 UTC
if the fix is in the current update, i would like to have it resubmitted
Comment 6 Sascha Peilicke 2013-12-06 13:28:54 UTC
sr#29776
Comment 8 Swamp Workflow Management 2013-12-17 09:26:35 UTC
The SWAMPID for this issue is 55533.
This issue was rated as moderate.
Please submit fixed packages until 2013-12-31.
When done, please reassign the bug to security-team@suse.de.
Patchinfo will be handled by security team.
Comment 9 Yury Tsarev 2014-01-22 16:55:56 UTC
Testing maintenance update candidate 

MD5SUM         : 3ac1770b48f8df2913e60fe8fc0e81ab
SWAMP ID       : 55534

I've followed the steps of original reproducer in https://bugs.launchpad.net/ossn/+bug/1179955


The token does not appear to be revoked:


d00-00-1a-1a-23-75:~ # keystone tenant-update --enabled false ${DEMO_TENANT}
d00-00-1a-1a-23-75:~ # keystone tenant-list |grep demo
| 275de3f7555c4d09a6b80459ed536fbe |                demo                |  False  

d00-00-1a-1a-23-75:~ # curl -i -H 'X-Auth-Token: ${TOKEN}'  http://d00-00-1a-1a-23-75.cloud.qam.suse.de:8774/v2/275de3f7555c4d09a6b80459ed536fbe/servers
HTTP/1.1 200 OK
X-Compute-Request-Id: req-7324f475-c6fe-4a25-8b2e-9e3df904e15a
Content-Type: application/json
Content-Length: 415
Date: Wed, 22 Jan 2014 15:15:03 GMT

{"servers": [{"id": "0c2191d9-ae24-4050-9a79-fbb43a2c1e71", "links": [{"href": "http://d00-00-1a-1a-23-75.cloud.qam.suse.de:8774/v2/275de3f7555c4d09a6b80459ed536fbe/servers/0c2191d9-ae24-4050-9a79-fbb43a2c1e71", "rel": "self"}, {"href": "http://d00-00-1a-1a-23-75.cloud.qam.suse.de:8774/275de3f7555c4d09a6b80459ed536fbe/servers/0c2191d9-ae24-4050-9a79-fbb43a2c1e71", "rel": "bookmark"}], "name": "instance544437"}]}

I've tested swift, nova and dashboard session.

Token gets invalid in approximately 10 minutes. 

The same behavior can be observed before applying maintenance update candidate.

Vincent, please clarify how to proceed with this bug.
Comment 10 Vincent Untz 2014-01-23 07:32:29 UTC
Well, in that case, clearly we're missing some bit for the update.

Sascha, can you investigate?
Comment 11 Sascha Peilicke 2014-01-29 15:15:19 UTC
(In reply to comment #9)
> Token gets invalid in approximately 10 minutes. 

Tokens are valid 86400s (1 day) by default. So the window is much smaller. Strangely, the token revocation list seems to be fetched every second (default) by services that use keystone_authtoken middleware...


> The same behavior can be observed before applying maintenance update candidate.

If I am correct, we already have openstack-keystone-2013.1.4.a7.gafbc75b-0.7.7.x86_64.rpm in the Cloud-2 updates channel. This is exactly the version that included the upstream fix, the maintenance update only added the bnc / CVE metadata.




When looking at the database tables, tokens are invalidated immediately. Before (the user_id is my 'demo' user under the 'demo' tenant):


keystone=# select id,expires,valid,trust_id from token where user_id='5f486a3b8dbe4433a730fd29796ea6c7' and valid = 't';
                id                |          expires           | valid | trust_id
----------------------------------+----------------------------+-------+----------
 e7ddb2b71a101db980b7004467bafa15 | 2014-01-30 14:50:11.952488 | t     |
 148799f2b483f48888a87fc3675690e6 | 2014-01-30 14:50:29.375226 | t     |
(2 rows)


So there are two valid tokens that will expire tomorrow (from now). And after:


$ keystone tenant-update --enable false demo 

keystone=# select id,expires,valid,trust_id from token where user_id='5f486a3b8dbe4433a730fd29796ea6c7' and valid = 't';
 id | expires | valid | trust_id 
----+---------+-------+----------
(0 rows)


So tokens are invalidated, only the propagation seems to take longer...
Comment 12 Yury Tsarev 2014-01-29 15:27:10 UTC
Sascha, thanks a lot for investigation!


>If I am correct, we already have
>openstack-keystone-2013.1.4.a7.gafbc75b-0.7.7.x86_64.rpm in the Cloud-2 updates
>channel. This is exactly the version that included the upstream fix, the
>maintenance update only added the bnc / CVE metadata.

Ok, that was quite confusing...


Vincent, I guess now we are fine to release ?
Comment 13 Vincent Untz 2014-01-29 15:38:21 UTC
(In reply to comment #12)
> Vincent, I guess now we are fine to release ?

Yes.
Comment 14 Swamp Workflow Management 2014-01-30 17:46:53 UTC
Update released for: openstack-keystone, openstack-keystone-doc, openstack-keystone-test, python-keystone
Products:
SUSE-CLOUD 2.0 (x86_64)
Comment 15 Swamp Workflow Management 2014-01-30 21:05:50 UTC
SUSE-SU-2014:0163-1: An update that solves two vulnerabilities and has two fixes is now available.

Category: security (moderate)
Bug References: 837800,839876,843443,848066
CVE References: CVE-2013-4222,CVE-2013-4477
Sources used:
SUSE Cloud 2.0 (src):    openstack-keystone-2013.1.5.a2.g82dcde0-0.7.1, openstack-keystone-doc-2013.1.5.a2.g82dcde0-0.7.1
Comment 16 Marcus Meissner 2014-03-24 08:33:33 UTC
released