Bugzilla – Bug 829080
VUL-0: CVE-2013-2255: openstack various SSL hostname checking problems
Last modified: 2014-01-20 12:24:29 UTC
public, via openstack https://bugs.launchpad.net/keystone/+bug/1188189 CVE-2013-2255 Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/
(WOnder if and how our last python change could make this better?)
https://bugs.launchpad.net/bugs/cve/2013-2255 keystone, cinder, nova, swift, python-keystoneclient
Doesn't impact SUSE Cloud 1.0 (since we were using apache for SSL), so no update required there. cc'ing Sascha to get his opinion on this.
bugbot adjusting priority
The whole Py2.x SSL story is summarized here: http://wiki.python.org/moin/SSL. As an aside, the ovirt "solution's" only improvement seems to be that they check if the server cert is valid. They still don't check if it actually belongs to the host. Upstream doesn't yet seem to have decided on any solution, but IMO it's best to move to the "requests" lib everywhere. It does cert validation and hostname checking. For Cloud-1, it's the same issue, keystoneclient uses httplip.HTTPSConnection when auth_protocol is https (default), so it won't validate the (keystone) server cert nor if the cert matches the hostname. I would recommend backporting the upstream solution for Folsom once it's there. About the impact: I don't want to play down the issue but if the keystone server is captured, the whole cloud is considered compromised anyway. The keystone server certs are owned by the (openstack-)keystone user (usually in /etc/keystone/ssl...), but an attacker wouldn't waste time replacing SSL certs, he already owns all (user/admin) tokens anyway.
The following was suggested over the OpenStack Security ML: https://bugs.launchpad.net/keystone/+bug/1188189/comments/32 ... ### Recommended Actions ### Consider using an up to date version of the keystone client http://github.com/openstack/python-keystoneclient/commit/20e166fd8a943ee3f91ba362a47e9c14c7cc5f4c ... Was there anything else discussed or submitted upstream?
(In reply to comment #6) > The following was suggested over the OpenStack Security ML: > > https://bugs.launchpad.net/keystone/+bug/1188189/comments/32 > > ... > ### Recommended Actions ### > Consider using an up to date version of the keystone client > http://github.com/openstack/python-keystoneclient/commit/20e166fd8a943ee3f91ba362a47e9c14c7cc5f4c That indeed addresses the issue. I'm currently torn between bringing python-keystoneclient up the most recent version or backporting that single commit. Updating is a lot more trouble than it sounds since that includes additional dependencies (not part of Cloud-2 GM) and potential version conflicts for dependencies shared with other OS components. I guess I'll backport the fix. > Was there anything else discussed or submitted upstream? Not to my knowledge.
Backport in Devel:Cloud:2.0:Staging...
sr#29645
Update released for: python-keystoneclient, python-keystoneclient-doc, python-keystoneclient-test Products: SUSE-CLOUD 2.0 (x86_64)
SUSE-SU-2014:0089-1: An update that fixes three vulnerabilities is now available. Category: security (moderate) Bug References: 824818,829080 CVE References: CVE-2013-2166,CVE-2013-2167,CVE-2013-2255 Sources used: SUSE Cloud 2.0 (src): python-keystoneclient-0.2.3-0.19.1
done