Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 480476 (CVE-2013-4222) - sys-auth/keystone: Disabling a tenant does not disable a user token (CVE-2013-4222)
Summary: sys-auth/keystone: Disabling a tenant does not disable a user token (CVE-2013...
Status: RESOLVED FIXED
Alias: CVE-2013-4222
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal trivial (vote)
Assignee: Gentoo Security
URL: https://bugzilla.redhat.com/show_bug....
Whiteboard: ~4 [noglsa]
Keywords:
Depends on:
Blocks:
 
Reported: 2013-08-10 10:19 UTC by Agostino Sarubbo
Modified: 2013-10-02 15:00 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 2013-08-10 10:19:06 UTC
From ${URL} :

### Summary ###
When a tenant is disabled in Keystone, tokens that have been issued to
that tenant are not invalidated. This can result in users having access
to your cloud after you have attempted to revoke them.

### Affected Services / Software ###
Keystone

### Discussion ###
It appears that Keystone does not purge the tokens given out to tenants
when a tenant is disabled. In some scenarios this could be very
important to cloud providers. Take the case where a cloud provider must
a tenant's access because of some legal investigation. Even though the
tenant is disabled it would be possible for them to terminate VMs /
delete Swift files etc. - There are many other abuse-cases...

### Recommended Actions ###
How the tokens are stored depends on your cloud deployment. If you
deploy using Memcache to back Keystone then flushing the cash when
disabling a token would resolve this issue for you, at the cost of other
token lookups which are no longer in the cash requiring Keystone
interaction.

It is of course possible to script something to remove tokens from any
backend DB or cache but there is no 'official' way to do this.

### Contacts / References ###
Proposed Fix : https://review.openstack.org/#/c/39878/
This OSSN : https://bugs.launchpad.net/ossn/+bug/1179955
OpenStack Security ML : openstack-security at lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg

References:
http://lists.openstack.org/pipermail/openstack-security/2013-August/000263.html


@maintainer(s): after the bump, in case we need to stabilize the package, please say explicitly if it is ready for the stabilization or not.
Comment 1 Chris Reffett (RETIRED) gentoo-dev Security 2013-08-12 00:10:01 UTC
Patch is currently under consideration by upstream. Can either apply it now or wait for inclusion in the next release.
Comment 2 Matthew Thode ( prometheanfire ) archtester Gentoo Infrastructure gentoo-dev Security 2013-08-12 04:36:43 UTC
I am comfortable taking the patch if it's been committed to master (and preferably to the stable branches).
Comment 3 Chris Reffett (RETIRED) gentoo-dev Security 2013-08-27 01:10:57 UTC
Looks like patch was merged into upstream master. Not certain whether it's been released anywhere.
Comment 4 Matthew Thode ( prometheanfire ) archtester Gentoo Infrastructure gentoo-dev Security 2013-09-11 18:04:09 UTC
I'm pretty sure that this is a bug in Havana only so does not effect us.  I will let you know when I verify.
Comment 5 Matthew Thode ( prometheanfire ) archtester Gentoo Infrastructure gentoo-dev Security 2013-09-12 19:48:33 UTC
ok, it is a grizzly issue.  Also, upstream is 50/50 on whether or not they will backport.
Comment 6 Matthew Thode ( prometheanfire ) archtester Gentoo Infrastructure gentoo-dev Security 2013-09-15 03:00:38 UTC
fix present in the following versions

via non-upstream-merged patch
keystone-2012.2.4-r9
keystone-2013.1.3-r3
keystone-2013.1.9999

via upstream-merged patch
keystone-9999

no vulnerable stuff in tree, removing myself from cc, feel free to add me if more work is needed.
Comment 7 Chris Reffett (RETIRED) gentoo-dev Security 2013-09-15 03:01:32 UTC
noglsa. Done here.
Comment 8 Chris Lu 2013-09-19 18:34:10 UTC
CVE changes are now in stable/grizzly, causing the patch and ebuild to fail.

https://github.com/openstack/keystone/tree/stable/grizzly

 * Failed Patch: 2013.1.3-CVE-2013-4222.patch !
 *  ( /usr/portage/sys-auth/keystone/files/2013.1.3-CVE-2013-4222.patch )
 *
 * Include in your bugreport the contents of:
 *
 *   /var/tmp/portage/sys-auth/keystone-2013.1.9999/temp/2013.1.3-CVE-2013-4222.patch-2868.out

 * ERROR: sys-auth/keystone-2013.1.9999::gentoo failed (prepare phase):
 *   Failed Patch: 2013.1.3-CVE-2013-4222.patch!
 *
 * Call stack:
 *     ebuild.sh, line   93:  Called src_prepare
 *   environment, line 4233:  Called distutils-r1_src_prepare
 *   environment, line 1157:  Called distutils-r1_python_prepare_all
 *   environment, line 1076:  Called epatch '/usr/portage/sys-auth/keystone/files/2013.1.3-CVE-2013-4222.patch'
 *   environment, line 1796:  Called die
 * The specific snippet of code:
 *               die "Failed Patch: ${patchname}!";
 *
 * If you need support, post the output of `emerge --info '=sys-auth/keystone-2013.1.9999::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=sys-auth/keystone-2013.1.9999::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/sys-auth/keystone-2013.1.9999/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/sys-auth/keystone-2013.1.9999/temp/environment'.
 * Working directory: '/var/tmp/portage/sys-auth/keystone-2013.1.9999/work/keystone-2013.1.9999'
 * S: '/var/tmp/portage/sys-auth/keystone-2013.1.9999/work/keystone-2013.1.9999'
qemu2 keystone #
Comment 10 Matthew Thode ( prometheanfire ) archtester Gentoo Infrastructure gentoo-dev Security 2013-09-19 19:31:06 UTC
fixed
Comment 11 GLSAMaker/CVETool Bot gentoo-dev 2013-10-02 15:00:56 UTC
CVE-2013-4222 (http://nvd.nist.gov/nvd.cfm?cvename=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 authenticated users to retain access via the
  token.