New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SSL module fails to handle NULL bytes inside subjectAltNames general names (CVE-2013-4238) #62909
Comments
Ryan Sleevi of the Google Chrome Security Team has informed us that Python's SSL module doesn't handle NULL bytes inside subjectAltNames general names. It's related to Ruby's CVE-2013-4073 http://www.ruby-lang.org/en/news/2013/06/27/hostname-check-bypassing-vulnerability-in-openssl-client-cve-2013-4073/ Although Python uses a slightly different OpenSSL API to parse a X.509 certificate and turn its fields into a dictionary, our implementation eventually uses an OpenSSL function that fails to handle NULL bytes. This could lead to a breach when an application uses ssl.match_hostname() to match the hostname againt the certificate's subjectAltName's dNSName general names. When the Ruby issues was announced publicly I already suspected that our code may suffer from the same issue. But I was unable to generate a X.509 certificate with a NULL byte in its X509v3 subjectAltName extension, only in subject and issuer. OpenSSL's config file format just didn't support NULL bytes. But Our code handled the NULL byte in subject in issuer just fine so I gave up. In the light of the bug report I went a different path and eventually I came up with a malicious certificate that showed the reported bug. |
Demo certificate: Certificate: The correct values are: (('DNS', 'altnull.python.org\x00example.com'), |
Does it really make sense to allow to open a certificate containing a NUL byte in its name? How does OpenSSL and other projects handle this case? |
OpenSSL's print() functions fail to handle the NULL byte in subjectAltName (SAN) general names as they use strlen() or printf() functions with "%s" format char. The subject and issuer elements with NULL bytes are handled correctly by OpenSSL. wget and curl combine CN / SAN parsing and hostname matching in one function. Both report an error when they see a NULL byte in a dNSName (strlen(dNSName) != lengtt of ASN1_STRING). Python has separate functions for retrieving the X.509 information and matching a hostname against CN / SAN. I like to keep it that way and just for our parsing code in this bug. Latter ssl.match_hostname() can check for NULL bytes and raise an exception, but that's a different issue. |
This issue has been assigned CVE-2013-4238 [1]. Please use CVE-2013-4238 for this issue in Python for patches and references. |
Thanks! The title now references the new CVE #. |
Python 3.1 is affected, too. 3.1 will recieve security fixes until June 2014. |
Brian Cameron from Oracle has requested a fix for Python 2.6. I have attached a patch for 2.6. In order to compile and test the patch I had to modify _ssl.c to handle OPENSSL_NO_SSL2. I also copied keycert.pem from 2.7 to fix two test failures. The former keycert.pem has expired. It's a bit of a challenge to compile Python 2.6 on modern Linux OS. I had to set a couple of flags and overwrite MACHDEP: export arch=$(dpkg-architecture -qDEB_HOST_MULTIARCH) |
For the record PHP has assigned CVE-2013-4248 for the issue. |
New changeset c9f073e593b0 by Christian Heimes in branch '3.3': New changeset 7a0f398d1a5c by Christian Heimes in branch 'default': New changeset bd2360476bdb by Christian Heimes in branch '2.7': |
I have applied the patch to 2.7, 3.3 and 3.4. Barry, Benjamin, Georg: |
New changeset 79007c4244d6 by Barry Warsaw in branch '2.6':
|
The test is failing on Tiger buildbots: """ Traceback (most recent call last):
File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_ssl.py", line 230, in test_parse_cert_CVE_2013_4238
('IP Address', '2001:DB8:0:0:0:0:0:1\n'))
AssertionError: Tuples differ: (('DNS', 'altnull.python.org\x... != (('DNS', 'altnull.python.org\x... First differing element 4: (('DNS', 'altnull.python.org\x00example.com'),
('email', 'null@python.org\x00user@example.org'),
('URI', 'http://null.python.org\x00http://example.org'),
('IP Address', '192.0.2.1'),
- ('IP Address', '<invalid>'))
+ ('IP Address', '2001:DB8:0:0:0:0:0:1\n')) """ http://buildbot.python.org/all/builders/x86 Tiger 3.x/builds/6829/steps/test/logs/stdio |
New changeset 004743d210e4 by Christian Heimes in branch '3.3': New changeset 577e9402cadd by Christian Heimes in branch 'default': New changeset 1cd24ea5abeb by Christian Heimes in branch '2.7': New changeset 50803d881a92 by Christian Heimes in branch '2.6': |
Tiger has OpenSSL 0.9.7 which doesn't support IPv6 addresses. I have added a workaround. |
It's not fixed in 3.1 and 3.2 yet. Please re-open the issue. I can't do it because I'm not at home. "Charles-François Natali" <report@bugs.python.org> schrieb:
|
Oops. |
Doing 'valgrind --suppressions=valgrind-python.supp ./python Lib/tests/regrtest.py test_ssl.py' I'm getting ==11944== LEAK SUMMARY: and as far as I can tell the leak is introduced by this patch, I can't seem to figure out what could be causing it though. |
I can't reproduce the memory leak. valgrind's output doesn't show suspicious memory leaks. ./configure --with-pydebug --config-cache Python 3.4 tip ==26085== HEAP SUMMARY: Python 3.4.0a1 (without patch) Python 2.7 tip ==3184== HEAP SUMMARY: |
Oh, I only checked the particular commit that fixed this issue in 2.6 (50803d881a92). I am not getting any leaks in 2.6 tip either, so I guess it was fixed somewhere along the way. Sorry for the confusion! |
New changeset 90040e560527 by Christian Heimes in branch '3.3': New changeset 4e93f32176fb by Christian Heimes in branch 'default': New changeset 07ee48ce4513 by Christian Heimes in branch '2.6': New changeset a7d5b86ffb95 by Christian Heimes in branch '2.7': |
Christian, is the -py32 patch still up to date? |
I'm removing 2.6 from the Versions field since AFAIK we've resolved this issue for 2.6. This way it'll be easier to scan the blockers for 2.6.9. If anyone things we still have things to address for this issue in 2.6.9, please reassign it or follow up. |
So, this is fixed, but there's some suspicion of a memory leak? |
There's no longer any suspicion, no, at least from my side. |
I don't get it. Has somebody found a memory leak in my patch? Larry, I have removed 2.7, 3.3 and 3.4 from the affected versions. They fix has already landed. 3.1 and 3.2 are still open, though. Georg, the patch for 3.2 is still up to date. Are you going to commit it? |
The patch hasn't been committed to 3.2 yet. |
Not sure if 3.2 is still open to security fixes. |
New changeset 386b0f478117 by Georg Brandl in branch '3.2': |
Do we have patch for 3.1 version, or 3.2 patch will be also OK? |
These Python versions no longer receive security updates. Please update. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: