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.
Patch is currently under consideration by upstream. Can either apply it now or wait for inclusion in the next release.
I am comfortable taking the patch if it's been committed to master (and preferably to the stable branches).
Looks like patch was merged into upstream master. Not certain whether it's been released anywhere.
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.
ok, it is a grizzly issue. Also, upstream is 50/50 on whether or not they will backport.
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.
noglsa. Done here.
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 #
https://github.com/openstack/keystone/commit/afbc75b08add8fb5201f4ca7ccf1b7353fab138c
fixed
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.
