Bug 1178921 (CVE-2015-0210)

Summary: CVE-2015-0210 wpa_supplicant: broken certificate subject check
Product: [Other] Security Response Reporter: Vasyl Kaigorodov <vkaigoro>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: carnil, dcbw, jrusnack, rkhan, security-response-team, thijs, wilco
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-01-28 14:56:43 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1178263, 1186806, 1215892    
Bug Blocks: 1178923    

Description Vasyl Kaigorodov 2015-01-05 16:28:45 UTC
It was reported [1] that wpa_supplicant does not properly check certificate subject name, which might lead to "man in the middle" attack.
Relevant part of the original report:

wpa_supplicant, linked against openssl performs this check:

    if (depth == 0 && match && os_strstr(buf, match) == NULL) {
        wpa_printf(MSG_WARNING, "TLS: Subject '%s' did not "
               "match with '%s'", buf, match);
        preverify_ok = 0;
        openssl_tls_fail_event(conn, err_cert, err, depth, buf,
                       "Subject mismatch",

strstr() is vulnerable to extension attack, for instance, one would like to
match on /CN=wireless.nikhef.nl, but explicitly not match on
wireless.nikhef.nl.honestachmed.tr. There is no way to implement a secure
EAP-TTLS/PEAP configuration using public certificates this way.

When linked against GnuTLS, the problem is even worse:

      if (i == 0) {
            /* TODO: validate subject_match and altsubject_match */

Now, it is current best practice to run EAP-TTLS/PEAP with public certificates,
because on Windows, this automatically pins the CN and CA from the certificate.

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1178263

Comment 1 Tomas Hoger 2015-01-28 14:56:43 UTC
In the discussion with upstream, it was determined that this CVE assignment was not correct, as subject_match was intended and documented and substring match against the whole subject string.  As this CVE got used publicly (e.g. in https://bugzilla.gnome.org/show_bug.cgi?id=341323#c28), this bug is made public as well.

It was realized that existing alternatives to subject_match - alt_subject_match and domain_suffix_match - do not provide commonly needed / expected behavior of an exact non-substring match against server name that can be listed in X.509 certificate's DNS subject alternative name or subject common name (CN).  Therefore, domain_match was introduced, that behaves similarly to domain_suffix_match (it compares defined name against DNS subjectAltNames and falls back to checking subject CN if certificate includes no DNS subjectAltNames) and does full name check.  Further details can be found in bug 1178263.

Comment 2 Doran Moppert 2020-02-11 00:28:59 UTC

Red Hat Product Security determined that this flaw was not a security vulnerability. See the Bugzilla link for more details.