ssl module and LibreSSL CVE-2018-8970
Hi, I like to share the story of a critical security bug with you. Contrary to other issues in TLS/SSL, it's a story with happy ending. Nobody was harmed. The bug was fixed before it affected the general population. Introduction ------------ Python's ssl.match_hostname() function was a source of several CVEs and other security bugs. After a long struggle, I decided to drop support for old OpenSSL releases and uses a new OpenSSL method to offload host name verification to OpenSSL. The improvement [1] eventually landed in Python 3.7. Nowadays OpenSSL verifies host name or IP address during the TLS/SSL handshake. Later I discovered that LibreSSL <= 2.6 did not have X509_VERIFY_PARAM_set1_host() [2]. We had to temporarily suspend support for LibreSSL. About two months later, LibreSSL caught up and released version 2.7.0 with support for the function. The bug ------- One day after the release of LibreSSL 2.7.0, I started to port Python 3.7 to LibreSSL. In matter of minutes I got the ssl module to compile and work with LibreSSL. All tests were passing -- except for negative the host name verification tests. LibreSSL was accepting all invalid host names as correct! Python's vigorous test suite had discovered a critical security bug in LibreSSL. It turned out that LibreSSL copied the implementation of X509_VERIFY_PARAM_set1_host(param, name, namelen) from BoringSSL and the documentation from OpenSSL. BoringSSL's implementation didn't support the special case of 0 as namelen parammeter. OpenSSL supports namelen = 0, which is interpreted as namelen=strlen(name). It is documented in OpenSSL's man page and was even recommended on OpenSSL's wiki as preferred way. Happy Ending ------------ So I got in contact with LibreSSL's security team and BoringSSL's security team [3]. Less than a day later, both libraries released fixes for the bug [4]. Mitre has assigned CVE-2018-8970 [5] to the bug. Disaster averted! BoringSSL's security issue [3] contains more information. Adam Langley lifted the restriction about an hour ago. I like to thank Bob Beck (LibreSSL), Adam Langley (Google) and David Benjamin (Google) for their assistance and cooperation. Regards, Christian [1] https://bugs.python.org/issue31399 [2] https://github.com/libressl-portable/portable/issues/381 [3] https://bugs.chromium.org/p/chromium/issues/detail?id=824799 [4] https://www.libressl.org/releases.html [5] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8970
Nice work! Something to add to our "finding C compiler bugs" list of
accomplishments. 😁
On Wed, Apr 4, 2018, 13:39 Christian Heimes,
Hi,
I like to share the story of a critical security bug with you. Contrary to other issues in TLS/SSL, it's a story with happy ending. Nobody was harmed. The bug was fixed before it affected the general population.
Introduction ------------
Python's ssl.match_hostname() function was a source of several CVEs and other security bugs. After a long struggle, I decided to drop support for old OpenSSL releases and uses a new OpenSSL method to offload host name verification to OpenSSL. The improvement [1] eventually landed in Python 3.7. Nowadays OpenSSL verifies host name or IP address during the TLS/SSL handshake.
Later I discovered that LibreSSL <= 2.6 did not have X509_VERIFY_PARAM_set1_host() [2]. We had to temporarily suspend support for LibreSSL. About two months later, LibreSSL caught up and released version 2.7.0 with support for the function.
The bug -------
One day after the release of LibreSSL 2.7.0, I started to port Python 3.7 to LibreSSL. In matter of minutes I got the ssl module to compile and work with LibreSSL. All tests were passing -- except for negative the host name verification tests. LibreSSL was accepting all invalid host names as correct! Python's vigorous test suite had discovered a critical security bug in LibreSSL.
It turned out that LibreSSL copied the implementation of X509_VERIFY_PARAM_set1_host(param, name, namelen) from BoringSSL and the documentation from OpenSSL. BoringSSL's implementation didn't support the special case of 0 as namelen parammeter. OpenSSL supports namelen = 0, which is interpreted as namelen=strlen(name). It is documented in OpenSSL's man page and was even recommended on OpenSSL's wiki as preferred way.
Happy Ending ------------
So I got in contact with LibreSSL's security team and BoringSSL's security team [3]. Less than a day later, both libraries released fixes for the bug [4]. Mitre has assigned CVE-2018-8970 [5] to the bug. Disaster averted!
BoringSSL's security issue [3] contains more information. Adam Langley lifted the restriction about an hour ago.
I like to thank Bob Beck (LibreSSL), Adam Langley (Google) and David Benjamin (Google) for their assistance and cooperation.
Regards, Christian
[1] https://bugs.python.org/issue31399 [2] https://github.com/libressl-portable/portable/issues/381 [3] https://bugs.chromium.org/p/chromium/issues/detail?id=824799 [4] https://www.libressl.org/releases.html [5] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8970
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/brett%40python.org
+1. Thanks!
Which tests?
On Wednesday, April 4, 2018, Christian Heimes
Hi,
I like to share the story of a critical security bug with you. Contrary to other issues in TLS/SSL, it's a story with happy ending. Nobody was harmed. The bug was fixed before it affected the general population.
Introduction ------------
Python's ssl.match_hostname() function was a source of several CVEs and other security bugs. After a long struggle, I decided to drop support for old OpenSSL releases and uses a new OpenSSL method to offload host name verification to OpenSSL. The improvement [1] eventually landed in Python 3.7. Nowadays OpenSSL verifies host name or IP address during the TLS/SSL handshake.
Later I discovered that LibreSSL <= 2.6 did not have X509_VERIFY_PARAM_set1_host() [2]. We had to temporarily suspend support for LibreSSL. About two months later, LibreSSL caught up and released version 2.7.0 with support for the function.
The bug -------
One day after the release of LibreSSL 2.7.0, I started to port Python 3.7 to LibreSSL. In matter of minutes I got the ssl module to compile and work with LibreSSL. All tests were passing -- except for negative the host name verification tests. LibreSSL was accepting all invalid host names as correct! Python's vigorous test suite had discovered a critical security bug in LibreSSL.
It turned out that LibreSSL copied the implementation of X509_VERIFY_PARAM_set1_host(param, name, namelen) from BoringSSL and the documentation from OpenSSL. BoringSSL's implementation didn't support the special case of 0 as namelen parammeter. OpenSSL supports namelen = 0, which is interpreted as namelen=strlen(name). It is documented in OpenSSL's man page and was even recommended on OpenSSL's wiki as preferred way.
Happy Ending ------------
So I got in contact with LibreSSL's security team and BoringSSL's security team [3]. Less than a day later, both libraries released fixes for the bug [4]. Mitre has assigned CVE-2018-8970 [5] to the bug. Disaster averted!
BoringSSL's security issue [3] contains more information. Adam Langley lifted the restriction about an hour ago.
I like to thank Bob Beck (LibreSSL), Adam Langley (Google) and David Benjamin (Google) for their assistance and cooperation.
Regards, Christian
[1] https://bugs.python.org/issue31399 [2] https://github.com/libressl-portable/portable/issues/381 [3] https://bugs.chromium.org/p/chromium/issues/detail?id=824799 [4] https://www.libressl.org/releases.html [5] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8970
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ wes.turner%40gmail.com
participants (3)
-
Brett Cannon
-
Christian Heimes
-
Wes Turner