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?

bugbot adjusting priority

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

if the fix is in the current update, i would like to have it resubmitted

sr#29776

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.

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.

Well, in that case, clearly we're missing some bit for the update.

Sascha, can you investigate?

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

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 ?

(In reply to comment #12)
> Vincent, I guess now we are fine to release ?

Yes.

Update released for: openstack-keystone, openstack-keystone-doc, openstack-keystone-test, python-keystone
Products:
SUSE-CLOUD 2.0 (x86_64)

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

released