[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CANVjZ_R-e0M_JQ66CNpBN2YbcKj46gHyZYBCNoEj9WPA3JyNuw@mail.gmail.com>
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
