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/showbug.cgi?id=903885
This issue was fixed upstream in NSS 3.16: https://developer.mozilla.org/en-US/docs/NSS/NSS3.16releasenotes
The Network Security Services (NSS) library before 3.12.3, as used in Firefox; GnuTLS before 2.6.4 and 2.7.4; OpenSSL 0.9.8 through 0.9.8k; and other products support MD2 with X.509 certificates, which might allow remote attackers to spoof certificates by using MD2 design flaws to generate a hash collision in less than brute-force time. NOTE: the scope of this issue is currently limited because the amount of computation required is still large.
In his upcoming Blackhat paper and presentation Dan Kaminsky highlights some more issues he has found relating to SSL hash collisions and related vulnerabilities.
His second issue is all about inconsistencies in the interpretation of subject x509 names in certificates. Specifically "issue 2, attack 2c" regarding NULL terminators in a Common Name field. An attacker could create a malicious certificate containing a NULL, which, if they were able to get it signed, could confuse a client into accepting it by mistake.
According to the paper this is said to affect Firefox.
Integer underflow in the SSLv2 support in Mozilla Network Security Services (NSS) before 3.11.5, as used by Firefox before 1.5.0.10 and 2.x before 2.0.0.2, SeaMonkey before 1.0.8, Thunderbird before 1.5.0.10, and certain Sun Java System server products before 20070611, allows remote attackers to execute arbitrary code via a crafted SSLv2 server message containing a public key that is too short to encrypt the "Master Secret", which results in a heap-based overflow.