-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello,
(re-post from the Python developer list) last week Ryan Sleevi of the Google Chrome Security Team has informed us about about two issues in Python's SSL module. I already new about the cause of the first bug and suspected that our SSL module suffers from the second bug but I was unable to prove it. Both issues are security issues but their impact is limited if you trust only trustworthy root certification authorities. Any decent root CA would should not sign a malicious cert with NULL bytes in a subjectAltName dNSName field or with wildcards like *.*.com. By the way if you are using the cacert.pem from curl, please update your bundle ASAP. I have found a bug in its Mozilla certdata parser, too. bug #1: ssl.match_hostname() wildcard matching - ---------------------------------------------- ssl.match_hostname() doesn't implement RFC 6125 wildcard matching rules. Affected versions: - - Python 3.2 (< 3.2.5) - - Python 3.3 (< 3.3.3) - - Python 3.4a1 - - requests < 1.2.3 https://pypi.python.org/pypi/requests - - backports.ssl_match_hostname (<3.2a3) https://pypi.python.org/pypi/backports.ssl_match_hostname/ - - urllib3 < 1.6 https://github.com/shazow/urllib3 Bug reports: http://bugs.python.org/issue17997 https://github.com/kennethreitz/requests/issues/1528 https://bitbucket.org/brandon/backports.ssl_match_hostname/issue/2/match_hostname-doesnt-implement-rfc-6125 Patch: http://bugs.python.org/issue17997 has a preliminary patch. The handling of IDN A-labels is still a bit controversial, though. bug #2 failure to handle NULL bytes in subjectAltName - ----------------------------------------------------- It's basically the same issue as CVE-2013-4073. Python uses GENERAL_NAME_print() to turn a GERNAL_NAME entry into a C string. But GENERAL_NAME_print() doesn't handle embedded NULL bytes in ASN1_STRINGs correctly. You can read more about the issue at http://www.ruby-lang.org/en/news/2013/06/27/hostname-check-bypassing-vulnerability-in-openssl-client-cve-2013-4073/ Affected versions: - - Python 2.6 (< 2.6.8) - - Python 2.7 (< 2.7.5) - - Python 3.2 (< 3.2.5) - - Python 3.3 (< 3.3.3) - - Python 3.4a1 - - PyOpenSSL < 0.13 https://pypi.python.org/pypi/pyOpenSSL - - eGenix.com pyOpenSSL Distribution with PyOpenSSL < 0.13 https://pypi.python.org/pypi/M2Crypto - - M2Crypto < 0.21.1 http://www.egenix.com/products/python/pyOpenSSL/ Bug report: http://bugs.python.org/issue18709 Patches: http://bugs.python.org/issue18709 has patches for 2.7, 3.3 and default https://code.launchpad.net/~heimes/pyopenssl/pyopenssl/+merge/179673 Jean-Paul Calderone is going to release 0.13.1 soonish. It's going to contain just my fix for the issue. Marc-Andre Lemburg will build a new version of eGenix.com pyOpenSSL Distribution shortly after. I'm not going to work on a patch for M2Crypto as I don't understand SWIG. I have contacted Heikki Toivonen for M2Crypto but haven't heard back from him yet. related issue: Mozilla's certdata.txt and CKT_NSS_MUST_VERIFY_TRUST - ------------------------------------------------------------------- Recently I found bugs in curl's mk-ca-bundle.pl script, its cacert.pem and in the CA bundle of eGenix.com pyOpenSSL Distribution. Both failed to handle a new option in Mozilla's certdata.txt database correctly. As a consequence the root CA bundles contained additionally and untrustworthy root certificates. I'm not sure about the severity of the issue. Curl has already fixed its script week ago. Marc-Andre Lemburg is going to release a new distribution very soon. https://github.com/bagder/curl/commit/51f0b798fa http://curl.haxx.se/docs/caextract.html Background information: https://www.imperialviolet.org/2012/01/30/mozillaroots.html http://lists.debian.org/debian-release/2012/11/msg00411.html http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-existing.html I like to thank Ryan Sleevi (Google), Chris Palmer (Google), Marc-Andre Lemburg (eGenix.com, Python core dev), Jean-Paul Calderone (PyOpenSSL), Antoine Pitrou (Python core dev), Daniel Stenberg (curl), Günter Knauf (curl) and everybody else who was involved in reporting and fixing these issues. Regards, Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCgAGBQJSCRlqAAoJEMeIxMHUVQ1Fmq0QAJoKFK3V1iiB+3hhvPfJGnLn pSMzm9CpIineF7KRSI50GYls7gwO5Nggqol2V7qcEzpRCPFxkV9E2t75Q8OnBW0+ ZHOoTjpLD086HeQ4oIcGN6byQcHwIbIVh74hRFu7ZW4jqLQwvyPrGwRonRv5a6nG 0tRqp/Swqyqvo4KTpxV26MdZNwD+c+ASO0gmQzW6SURS5/gUKv0fDWjUwqC9COdZ Xz9wsLZaul+e6ewH7N5c7EWRXEs8l8cVk68Jw+/Jshct4kfWUnnw67qPjcoDgHLI tZzjVy7aCp2V9vjKvAcM2OUz0Q5h1rIFc5Roh5yH8OxuOn+Zn6zs3M6DKHJI9n12 JTTyi4yBu5hBRFqOWYSicytQpHAT604zpaGY7g4Hd0J98tG0kuT0BC7tozdi+MUW eXuBML7uYOBlI/VCIv/baZAaRj1txPZl5Vf9a75N2lb2seavUJDu8HqOzh+zxSTC 9agPuGAJOrU5mljkBKCCVy6/4njktjOBDmQsf9OHZ0/FolBjQuiJyXp4hLMQMqzY /ji4HtLF7Er0hWfj9L/4bFHf+XO9e9RZY8RtCV4ruc0fjZuZEt6SKx6CDjhMha8A zkWa2X5jk4RivBE1rMLovCaYeI8pt7cYcNmarZHBwjXjAKHR4xbxAPlP8KCQnvHt owYFnlto9YI6ZVndgsD/ =uPVK -----END PGP SIGNATURE----- -- http://mail.python.org/mailman/listinfo/python-list