[Python-Dev] SSL issues in Python stdlib and 3rd party code

[Christian Heimes]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello,

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/

iQIcBAEBCgAGBQJSCRjUAAoJEMeIxMHUVQ1F81UP/R8RqAFR3cODI4SgFzmvOSXa
u5OHfdQcgVfQbs5+oeZgqBu5aQ2W4SHKd/wSqCCrB1CbsZDZu9Y5LRVo/MgKMuNs
/c49FAyNKGUPc04RtBPfjSQ8GWlk4ziayW9PAuziBGD+ExMlSzXk1CwRwPJVPMkA
8xV48QThT4U5L1WRS4AH3XdgIpPWwJswNCuw9KjlIP/b1LZIrVvUg9rb4azVf0qu
Am9IlCwIb2sMNQU1s+sADht6B3Ka4tC8ej8VoWHnTEh8T8RJgcG3j3P2GFPx0YzD
35ISU6k/Dg/dEIJjawI7Uk+dXqxhMfCWFz5Yoy7TaUtYTFAFISqys88+I/H3PxNV
mewUNdRFO9ej2vyikI8s1FwGVaORYEIVtkOKzLRa7mc5ZEdh6MjZ2l3bH2GszO+J
mRzDwQjipnp8NwOjn9eipdKNaywFoGnDmoydxf3w9Qq6MPsdSiqtBHPWRP5K+091
rM+49v0MAenvxtkb8IJsBbSzVMs66uwfRYl1KYyvXNpGb4TSH/GlrUqRqaX97NW2
x1NprclxVWri5/kWnV4YvqJ6OmDcigCVI780+rQFSoqMk4JKDUgUsl451KvB4ATL
5OfZ9VaVhXu6Ydrjb3bRZHuKGeRsSH7JQCURFzWiriQEGwQAg/9D19JLli6YpCBZ
a5dEBzj4FAVglJEYlsZ2
=Jq/C
-----END PGP SIGNATURE-----