Red Hat Bugzilla – Bug 1079851
CVE-2014-1492 nss: IDNA hostname matching code does not follow RFC 6125 recommendation (MFSA 2014-45)
Last modified: 2014-09-18 04:28:11 EDT
In a wildcard certificate, the wildcard character should not be embedded within the U-label of an internationalized domain name. This was not properly implemented in NSS, as a result it did not handle IDNA domain prefixes according to RFC 6125, section 6.4.3 "Checking of Wildcard Certificates". http://tools.ietf.org/html/rfc6125#section-6.4.3 Upstream patch: https://hg.mozilla.org/projects/nss/rev/15ea62260c21 https://hg.mozilla.org/projects/nss/rev/2ffa40a3ff55 https://hg.mozilla.org/projects/nss/rev/709d4e597979 Upstream bug (not public): https://bugzilla.mozilla.org/show_bug.cgi?id=903885 This issue was fixed upstream in NSS 3.16: https://developer.mozilla.org/en-US/docs/NSS/NSS_3.16_release_notes
The problem here is that NSS did not previously follow recommendation (SHOULD NOT rather than MUST NOT) related to handling of certificates with names including wildcards against IDNA hostnames. The problem can occur under following conditions: - user instructs an application with support for internationalized domain names (IDN) to visit a URL containing non-ASCII characters - server for the domain presents a wildcard certificate with a wildcard label that contains characters followed by * For example: - user enters URL: https://bücher.example.de - URL with unicode character is ASCII encoded as: https://xn--bcher-kva.example.de - server presents a certificate for name x*.example.de - NSS versions before 3.16 accept certificate as valid for the specified host even though RFC 6125 section 6.4.3 recommends it SHOULD NOT be accepted Few other factors that limit impact of this issue: - use of wildcard certificates that contains label with both normal characters and wildcard character is uncommon, many applications do not support those at all - anyone able to get a certificate for x*.example.de from a trusted CA is also likely to be able to obtain certificate for *.example.de from the same CA. Per RFC 6125, applications may accept such certificate when asked to connect to bücher.example.de This fix is more of a security hardening than a vulnerability fix, especially considering that the cited RFC discourages, but does not forbid previous behavior.
Statement: (none)
MFSA for fixes applied to Firefox 29 and Seamonkey 2.26: http://www.mozilla.org/security/announce/2014/mfsa2014-45.html
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2014:0917 https://rhn.redhat.com/errata/RHSA-2014-0917.html
IssueDescription: It was found that the implementation of Internationalizing Domain Names in Applications (IDNA) hostname matching in NSS did not follow the RFC 6125 recommendations. This could lead to certain invalid certificates with international characters to be accepted as valid.
This issue has been addressed in following products: Red Hat Enterprise Linux 7 Via RHSA-2014:1073 https://rhn.redhat.com/errata/RHSA-2014-1073.html
This issue has been addressed in the following products: Red Hat Enterprise Linux 5 Via RHSA-2014:1246 https://rhn.redhat.com/errata/RHSA-2014-1246.html