https://developer.mozilla.org/en-US/docs/NSS/NSS_3.14.5_release_notes https://developer.mozilla.org/en-US/docs/NSS/NSS_3.14.5_release_notes
+*nss-3.15.3 (14 Nov 2013) + + 14 Nov 2013; Lars Wendler <polynomial-c@gentoo.org> +nss-3.15.3.ebuild: + Security bump (bug #491234). +
http://www.mozilla.org/security/announce/2013/mfsa2013-103.html : Google developer Andrew Tinits reported a potentially exploitable buffer overflow that was fixed in both NSS 3.15.3 and NSS 3.14.5. Null Cipher buffer overflow (CVE-2013-5605) Mozilla developer Camilo Viecco discovered that if the verifylog feature was used when validating certificates then certificates with incompatible key usage constraints were not rejected. This did not directly affect Firefox but might affect other software using the NSS library CERT_VerifyCert can SECSuccess for bad certificates (CVE-2013-5606) Google security researcher Tavis Ormandy reported a runaway memset in certificate parsing on 64-bit computers leading to a crash by attempting to write 4Gb of nulls. Integer truncation in certificate parsing (CVE-2013-1741) Pascal Cuoq, RedHat developer Kamil Dudka, and Google developer Wan-Teh Chang found equivalent Netscape Portable Runtime (NSPR) library code suffered the same integer truncation. Avoid unsigned integer wrapping in PL_ArenaAllocate (CVE-2013-5607) NSS lowered the priority of RC4 in cipher suite advertisement so that more secure ciphers instead of RC4 are likely to be chosen by the server. This can help address the problem described by Nadhem AlFardan, Dan Bernstein, Kenny Paterson, Bertram Poettering and Jacob Schuldt in their paper "On the Security of RC4 in TLS." "On the Security of RC4 in TLS" plaintext recovery attack (CVE-2013-2566)
There's been no stabilizing of this package following its upload a week ago. Shouldn't this be tagged STABLEREQ?
CC'ing arches: dev-libs/nss-3.15.3 : KEYWORDS="alpha amd64 arm hppa ia64 ppc ppc64 sparc x86" www-client/firefox-bin-24.1.1 : KEYWORDS="amd64 x86" www-client/seamonkey-bin-2.22.1: KEYWORDS="amd64 x86" mail-client/thunderbird-bin-24.1.1 : KEYWORDS="amd64 x86"
Stable for HPPA.
(In reply to Ian Stakenvicius from comment #4) > CC'ing arches: > > dev-libs/nss-3.15.3 : KEYWORDS="alpha amd64 arm hppa ia64 ppc ppc64 sparc > x86" > > www-client/firefox-bin-24.1.1 : KEYWORDS="amd64 x86" > www-client/seamonkey-bin-2.22.1: KEYWORDS="amd64 x86" > mail-client/thunderbird-bin-24.1.1 : KEYWORDS="amd64 x86" Why stabilize those version instead of 17.x series?
(In reply to Agostino Sarubbo from comment #6) > (In reply to Ian Stakenvicius from comment #4) > > CC'ing arches: > > > > dev-libs/nss-3.15.3 : KEYWORDS="alpha amd64 arm hppa ia64 ppc ppc64 sparc > > x86" > > > > www-client/firefox-bin-24.1.1 : KEYWORDS="amd64 x86" > > www-client/seamonkey-bin-2.22.1: KEYWORDS="amd64 x86" > > mail-client/thunderbird-bin-24.1.1 : KEYWORDS="amd64 x86" > > Why stabilize those version instead of 17.x series? I think that ESR series are no longer maintained after next_ESR+1 is released. Firefox 25 was released, so there will be no more updates to 17.x series. So you will have to stabilize 24.x soon anyway due to security issues.
(In reply to Agostino Sarubbo from comment #6) > (In reply to Ian Stakenvicius from comment #4) > > CC'ing arches: > > > > dev-libs/nss-3.15.3 : KEYWORDS="alpha amd64 arm hppa ia64 ppc ppc64 sparc > > x86" > > > > www-client/firefox-bin-24.1.1 : KEYWORDS="amd64 x86" > > www-client/seamonkey-bin-2.22.1: KEYWORDS="amd64 x86" > > mail-client/thunderbird-bin-24.1.1 : KEYWORDS="amd64 x86" > > Why stabilize those version instead of 17.x series? 24.x is new esr branch, that is why we are moving to it. He has missed the source builds as well but we can fix that in a day or two.
amd64 stable
x86 stable
Something strange is happenning. Why www-client/firefox became stable on HPPA but not on amd64/x86? It seems that this bug is only targeting www-client/firefox-bin but then it is not clear why www-client/firefox became stable on HPPA...
CVE-2013-5606 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-5606): The CERT_VerifyCert function in lib/certhigh/certvfy.c in Mozilla Network Security Services (NSS) 3.15 before 3.15.3 provides an unexpected return value for an incompatible key-usage certificate when the CERTVerifyLog argument is valid, which might allow remote attackers to bypass intended access restrictions via a crafted certificate. CVE-2013-5605 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-5605): Mozilla Network Security Services (NSS) 3.14 before 3.14.5 and 3.15 before 3.15.3 allows remote attackers to cause a denial of service or possibly have unspecified other impact via invalid handshake packets. CVE-2013-1741 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-1741): Integer overflow in Mozilla Network Security Services (NSS) 3.15 before 3.15.3 allows remote attackers to cause a denial of service or possibly have unspecified other impact via a large size value.
ppc stable
ppc64 stable
CVE-2013-5607 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-5607): Integer overflow in the PL_ArenaAllocate function in Mozilla Netscape Portable Runtime (NSPR) before 4.10.2, as used in Firefox before 25.0.1, Firefox ESR 17.x before 17.0.11 and 24.x before 24.1.1, and SeaMonkey before 2.22.1, allows remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact via a crafted X.509 certificate, a related issue to CVE-2013-1741. CVE-2013-2566 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-2566): The RC4 algorithm, as used in the TLS protocol and SSL protocol, has many single-byte biases, which makes it easier for remote attackers to conduct plaintext-recovery attacks via statistical analysis of ciphertext in a large number of sessions that use the same plaintext.
arm stable
alpha stable
Will continue stabilizing in bug 493850 since we need to request another round of stables there anyway.
cleaned up as part of bug 493850; sec, please decide whether to glsa this or coalesce into that one.
Created a New GLSA request. For NSS only, binaries of Firefox, thunderbird, sea monkey are part of another GLSA already in progress. as part of Bug #493850
This issue was resolved and addressed in GLSA 201406-19 at http://security.gentoo.org/glsa/glsa-201406-19.xml by GLSA coordinator Mikle Kolyada (Zlogene).
Re-open for Mozilla things.
This issue was resolved and addressed in GLSA 201504-01 at https://security.gentoo.org/glsa/201504-01 by GLSA coordinator Kristian Fiskerstrand (K_F).
