[<prev] [next>] [day] [month] [year] [list]
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 [1]
(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. -- [2]
An example of real-world software affected by this is nginx [3], bypassing
certificate verification entirely and InspIRCd [4], 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 [5] 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 [6].
This issue got assigned CVE-2017-8301 [7].
## 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
[1]: https://github.com/libressl-portable/openbsd/commit/ddd98f8ea741a122952185a36c1396c14c2fda74
[2]: https://wiki.openssl.org/index.php/Manual:SSL_CTX_set_verify(3)
[3]: https://trac.nginx.org/nginx/ticket/1257
[4]: https://github.com/inspircd/inspircd/blob/5366dd2abd8fdeecf4a6ff173faf1f241d185628/src/modules/extra/m_ssl_openssl.cpp#L536
[5]: http://hg.nginx.org/nginx-tests/
[6]: https://github.com/libressl-portable/portable/issues/307#issuecomment-297469867
[7]: 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.
