Bug 829080 - (CVE-2013-2255) VUL-0: CVE-2013-2255: openstack various SSL hostname checking problems
(CVE-2013-2255)
VUL-0: CVE-2013-2255: openstack various SSL hostname checking problems
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:running:55331:moderate maint:re...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-11 14:59 UTC by Marcus Meissner
Modified: 2014-01-20 12:24 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-07-11 14:59:12 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/
Comment 1 Marcus Meissner 2013-07-11 15:00:00 UTC
(WOnder if and how our last python change could make this better?)
Comment 2 Marcus Meissner 2013-07-11 15:02:30 UTC
https://bugs.launchpad.net/bugs/cve/2013-2255

keystone, cinder, nova, swift, python-keystoneclient
Comment 3 Vincent Untz 2013-07-11 15:43:38 UTC
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.
Comment 4 Swamp Workflow Management 2013-07-11 22:00:37 UTC
bugbot adjusting priority
Comment 5 Sascha Peilicke 2013-07-15 08:45:52 UTC
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.
Comment 6 Alexander Bergmann 2013-09-20 09:50:18 UTC
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?
Comment 7 Sascha Peilicke 2013-10-02 11:49:12 UTC
(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.
Comment 8 Sascha Peilicke 2013-10-21 09:42:08 UTC
Backport in Devel:Cloud:2.0:Staging...
Comment 9 Sascha Peilicke 2013-11-28 08:33:18 UTC
sr#29645
Comment 11 Swamp Workflow Management 2014-01-17 14:45:43 UTC
Update released for: python-keystoneclient, python-keystoneclient-doc, python-keystoneclient-test
Products:
SUSE-CLOUD 2.0 (x86_64)
Comment 12 Swamp Workflow Management 2014-01-17 18:04:31 UTC
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
Comment 13 Sebastian Krahmer 2014-01-20 12:24:29 UTC
done