Bugzilla – Bug 909713
VUL-0: CVE-2014-9365: python: failure to validate certificates in the HTTP client with TLS
Last modified: 2018-03-01 16:56:13 UTC
rh#1173041 Alex Gaynor reports: """ When Python's standard library HTTP clients (httplib, urllib, urllib2, xmlrpclib) are used to access resources with HTTPS, by default the certificate is not checked against any trust store, nor is the hostname in the certificate checked against the requested host. It was possible to configure a trust root to be checked against, however there were no faculties for hostname checking. This made MITM attacks against the HTTP clients trivial, and violated RFC 2818 (http://tools.ietf.org/html/rfc2818#section-3). Python 2.7.9 has been issued to resolve this issue. It is also resolved in 3.4.3, which has not yet been released. """ CVE-2014-9365 was assigned to this issue. References: http://seclists.org/oss-sec/2014/q4/1022 https://bugzilla.redhat.com/show_bug.cgi?id=1173041
well, in https://bugzilla.suse.com/show_bug.cgi?id=827982 we fixed mod_ssl ... released July 2013, we check against the system trust store. hostname checking i am not fully aware, but I think we fixed issues in python modules already.
bugbot adjusting priority
this one is tough I'd mark SLE10's python 2.4 as "unaffected" - it does have a rudimentary ssl support, but the documentation clearly states that it doesn't do any certificate verification whatsoever, there are no methods to inspect certificates and therefore no way to check hostnames. Backporting current ssl module is unfeasible; implementing hostname verification would be difficult (basically adding a completely new feature), and moreover, we would either have to keep the verification off by default (so legacy apps will never use it), or on by default (in which case services relying on unverified ssl will break). In SLE11, we have python 2.6.9 with a patch to use system certificate store if none is provided. There are also methods to inspect peer certificate, but a method to check validity of hostname is missing. It can be either backported, or supplied as a third-party module (backports.match_hostname is a good candidate). In any case, there's a couple things speaking against backporting: 1. python's inability to properly verify certificates and hostnames is well-known and solved in several third-party libraries (pycurl, M2Crypto, requests) 2. we previously decided to keep certificate verification off by default, in line with upstream behavior; this doesn't seem to add reasons to reverse that decision 3. in conclusion, apps that care about this have already implemented a working solution, while apps that don't might as well simply break. 4. upstream's implementation of mandatory hostname checking largely relies on features of Python 3 ssl module; we could implement this feature separately, but backporting the whole API seems out of scope and our implementation would work in an ad-hoc SUSE-specific way Still, there's a large class of apps that would benefit from stricter checking, and backporting to 2.6.9 is possible. For SLE, it is my opinion that it would be best to leave this out of regular security maintenance, and implement it only on request. Factory already has python 2.7.9 which fixes the issue; there is FATE#318300 to update SLE12 as well. openSUSE 13.1 is on 2.7.5 and 13.2 on 2.7.8; if we want to fix this, i'd prefer upgrading both to 2.7.9 for the added benefit of the new ssl module. (once again, python's micro-version updates are behavior-compatible except for bugfixes, so this doesn't pose significant risks) As for Python 3, the fixed version has not yet been released by upstream. When it comes, we'll upgrade Factory and possibly openSUSE (same reasoning applies). Not sure about SLE12 which has 3.4.1. Depending on what else is fixed in the 3.4.3 release, i might try to push for a version-update. But it is much simpler to do a backport within the 3.4 line, so we could as well just patch this one thing. comments?
openSUSE - minor python 2 version upgrades is fine (should work seamless I think). Please submit. openSUSE - python3 ... please keep an eye on it, we will do an update if that happens. SLE12 - ECO for python2 is ongoing, will push on it. SLE12 - python3 Can we start with the simple backport fix first? We can discuss a minor version upgrade later on too. For SLE11 I have a bit of worry (same as you) that apps might break if we enable it. There I think we would need an ECO to get release notes and approvals from non-egnineering parties.
FATE 318300
In discussing the ECO in FATE 318300 the risk of breaking existing customer scenarios (local site setups mostly) was considered to be significant. So we will currently not pursue this as a backport, or only have it default disabled. bin/addnote CVE-2014-9365 "We are currently not planning to backport this security feature, on fear of breaking a significant percentage of customer scenarios on local sites with invalid SSL certificates. Future service packs and products will have this feature enabled by default."
was not python-backports.ssl_match_hostname the fix for this?
that was for python3 I think. anyway I think we are good