Ref: seclists.org/oss-sec/2017/q2/145
===================================================
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 () jirutka cz> from Alpine Linux
using the nginx automated test suite [5] and further investigated by
Duncan Overbruck <duncaen () voidlinux eu> from Void Linux and Shiz <hi () shiz 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


===================================================


(open-)SUSE: https://software.opensuse.org/package/libressl

2.5.3 (TW, official repo)
2.3.4 (42.2, official repo)
2.3.0 (42.1, official repo)