Date: Fri, 15 Jul 2016 10:14:52 +0200 From: Justin Ross <jross@...che.org> To: "users@...d.apache.org" <users@...d.apache.org>, "dev@...d.apache.org" <dev@...d.apache.org>, announce@...che.org, security@...che.org Cc: oss-security@...ts.openwall.com, bugtraq@...urityfocus.com Subject: [SECURITY] CVE-2016-4467: Apache Qpid Proton: Failure to verify that the server host name matches the certificate host name on Windows CVE-ID: CVE-2016-4467 Severity: Medium Affected versions: 0.8 through 0.13.0 (inclusive) Fixed in Versions: 0.13.1 and later Short Description: The Proton C client and C-based client bindings may fail to verify that the server host name matches the domain name in the subject's Common Name (CN) or subjectAltName field in X.509 certificates when running on Windows operating systems. Description: Messaging applications using the Proton C library to provide SSL/TLS authentication on Windows can falsely authenticate a server whose name does not match the server name in the connection specifier. Proton C bindings are affected to a greater or lesser degree depending on how they use the underlying Proton C library. In Proton C, this can only happen if PN_SSL_VERIFY_PEER_NAME has been specified as the verification mode and pn_ssl_set_peer_hostname() has not been called at all or has been called with a NULL value for a particular pn_ssl_t object. In the Proton C++ binding, this will always happen unless the application has separately specified a virtual_host name for an SSL/TLS connection. In the Proton Python and Ruby bindings, this will only happen if the application has separately specified a NULL virtual_host name for an SSL/TLS connection after creating the connection but before the authentication step. This issue only occurs on Windows versions of Proton that use the default SChannel-based security layer. In any of the preceding cases, it is possible for a man-in-the-middle attacker to spoof an SSL/TLS server if they had a certificate that was valid for any of the application's Certificate Authorities. Resolution: Proton release 0.13.1 resolves this issue in the SChannel-based security layer by obtaining a default non-NULL peer hostname from the associated connection address when initialized and by always failing hostname verification if PN_SSL_VERIFY_PEER_NAME has been specified along with a NULL peer hostname. This resolution matches the associated behaviour of the OpenSSL-based security layer. References: PROTON-1228 PROTON-1233
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ