Date: Thu, 27 Apr 2017 20:58:10 +0200 From: Jakub Jirutka <jakub@...utka.cz> To: oss-security@...ts.openwall.com Subject: CVE-2017-8301: TLS verification vulnerability in LibreSSL 2.5.1 - 2.5.3 Vulnerability Type: Missing TLS Certificate Validation Affected Product Code Base: LibreSSL - 2.5.1 - 2.5.3 Vendor of Product: OpenBSD Affected Component: SSL_set_verify, SSL_CTX_set_verify, SSL_get_verify_result ## Summary LibreSSL 2.5.1 to 2.5.3 lacks TLS certificate verification if SSL_get_verify_result is relied upon for a later check of a verification result, in a use case where a user-provided verification callback returns 1, as demonstrated by acceptance of invalid certificates by nginx. ## Additional Information LibreSSL versions from 2.5.1 until 2.5.3 suffer from a lack of TLS certificate verification if the user-provided callback for verification returns 1. This bug was introduced in commit ddd98f8ea741a122952185a36c1396c14c2fda74  (libcrypto/x509/x509_vfy.c, version 1.58) and has not been fixed upstream yet. If the user verification callback returns 1, LibreSSL will force the verification result to X509_V_OK resulting in, contrary to the documentation, any later checks by the API user through SSL_get_verify_result() to be useless, as it will always return X509_V_OK instead of any earlier error that occurred in the verification process. As such, any API user that matches the following prerequisites: * Installs a verification callback that always returns 1, or returns 1 even when the first parameter (preverify_ok) is 0; * Intends to check the verification result later using SSL_get_verify_result() in order to abort the connection at that point; will be lead into thinking that the verification succeeded and thus possibly allow connections to peers with invalid certificates, despite this clearly not being the intention and in violation of the documentation of the original OpenSSL API: > If verify_callback always returns 1, the TLS/SSL handshake will not be > terminated with respect to verification failures and the connection will be > established. The calling process can however retrieve the error code of the > last verification error using SSL_get_verify_result(3) or by maintaining > its own error storage managed by verify_callback. --  An example of real-world software affected by this is nginx , bypassing certificate verification entirely and InspIRCd , bypassing the option of requiring trusted clients upon connect (<connect requiressl="trusted">). This issue was discovered by Jakub Jirutka <jakub@...utka.cz> from Alpine Linux using the nginx automated test suite  and further investigated by Duncan Overbruck <duncaen@...dlinux.eu> from Void Linux and Shiz <hi@...z.me> from Alpine Linux. Not fixed upstream yet, verified by vendor here . This issue got assigned CVE-2017-8301 . ## Attack Vectors Connect to an affected service over TLS using an arbitrary client certificate, or an affected client connecting to a service that presents an arbitrary server certificate. ## References : https://github.com/libressl-portable/openbsd/commit/ddd98f8ea741a122952185a36c1396c14c2fda74 : https://wiki.openssl.org/index.php/Manual:SSL_CTX_set_verify(3) : https://trac.nginx.org/nginx/ticket/1257 : https://github.com/inspircd/inspircd/blob/5366dd2abd8fdeecf4a6ff173faf1f241d185628/src/modules/extra/m_ssl_openssl.cpp#L536 : http://hg.nginx.org/nginx-tests/ : https://github.com/libressl-portable/portable/issues/307#issuecomment-297469867 : https://nvd.nist.gov/vuln/detail/CVE-2017-8301
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.