Fixed in Firefox ESR 24.1 MFSA 2013-102 Use-after-free in HTML document templates MFSA 2013-101 Memory corruption in workers MFSA 2013-100 Miscellaneous use-after-free issues found through ASAN fuzzing MFSA 2013-99 Security bypass of PDF.js checks using iframes MFSA 2013-98 Use-after-free when updating offline cache MFSA 2013-97 Writing to cycle collected object during image decoding MFSA 2013-96 Improperly initialized memory and overflows in some JavaScript functions MFSA 2013-95 Access violation with XSLT and uninitialized data MFSA 2013-94 Spoofing addressbar though SELECT element MFSA 2013-93 Miscellaneous memory safety hazards (rv:25.0 / rv:24.1 / rv:17.0.10) Fixed in Firefox ESR 17.0.10 MFSA 2013-101 Memory corruption in workers MFSA 2013-100 Miscellaneous use-after-free issues found through ASAN fuzzing MFSA 2013-98 Use-after-free when updating offline cache MFSA 2013-96 Improperly initialized memory and overflows in some JavaScript functions MFSA 2013-95 Access violation with XSLT and uninitialized data MFSA 2013-93 Miscellaneous memory safety hazards (rv:25.0 / rv:24.1 / rv:17.0.10) Fixed in Thunderbird ESR 17.0.10 MFSA 2013-101 Memory corruption in workers MFSA 2013-100 Miscellaneous use-after-free issues found through ASAN fuzzing MFSA 2013-98 Use-after-free when updating offline cache MFSA 2013-96 Improperly initialized memory and overflows in some JavaScript functions MFSA 2013-95 Access violation with XSLT and uninitialized data MFSA 2013-93 Miscellaneous memory safety hazards (rv:25.0 / rv:24.1 / rv:17.0.10) Fixed in SeaMonkey 2.22 MFSA 2013-102 Use-after-free in HTML document templates MFSA 2013-101 Memory corruption in workers MFSA 2013-100 Miscellaneous use-after-free issues found through ASAN fuzzing MFSA 2013-98 Use-after-free when updating offline cache MFSA 2013-97 Writing to cycle collected object during image decoding MFSA 2013-96 Improperly initialized memory and overflows in some JavaScript functions MFSA 2013-95 Access violation with XSLT and uninitialized data MFSA 2013-94 Spoofing addressbar though SELECT element MFSA 2013-93 Miscellaneous memory safety hazards (rv:25.0 / rv:24.1 / rv:17.0.10)
+*seamonkey-2.22 (02 Nov 2013) + + 02 Nov 2013; Lars Wendler <polynomial-c@gentoo.org> +seamonkey-2.22.ebuild: + Security bump (bug #489796). +
thunderbird/firefox-24.1.0 are in tree ready to go stable. We are not gonna do 17.0.10 release we are moving esr to 24.1.0 ALL ebuilds are in tree we can bring in archs anytime.
CVE list is as follows: CVE-2013-5604 CVE-2013-5603 CVE-2013-5602 CVE-2013-5601 CVE-2013-5600 CVE-2013-5599 CVE-2013-5598 CVE-2013-5597 CVE-2013-5596 CVE-2013-5595 CVE-2013-5593 CVE-2013-5592 CVE-2013-5591 CVE-2013-5590 Note, MFSA 2013-93 also includes a listing of CVE-2013-1739 , which is for NSS, therefore only applies to *-bin packages.
CVE-2013-5604 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-5604): The txXPathNodeUtils::getBaseURI function in the XSLT processor in Mozilla Firefox before 25.0, Firefox ESR 17.x before 17.0.10 and 24.x before 24.1, Thunderbird before 24.1, Thunderbird ESR 17.x before 17.0.10, and SeaMonkey before 2.22 does not properly initialize data, which allows remote attackers to execute arbitrary code or cause a denial of service (stack-based buffer overflow and application crash) via crafted documents. CVE-2013-5603 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-5603): Use-after-free vulnerability in the nsContentUtils::ContentIsHostIncludingDescendantOf function in Mozilla Firefox before 25.0, Firefox ESR 24.x before 24.1, Thunderbird before 24.1, and SeaMonkey before 2.22 allows remote attackers to execute arbitrary code or cause a denial of service (heap memory corruption) via vectors involving HTML document templates. CVE-2013-5602 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-5602): The Worker::SetEventListener function in the Web workers implementation in Mozilla Firefox before 25.0, Firefox ESR 17.x before 17.0.10 and 24.x before 24.1, Thunderbird before 24.1, Thunderbird ESR 17.x before 17.0.10, and SeaMonkey before 2.22 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via vectors related to direct proxies. CVE-2013-5601 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-5601): Use-after-free vulnerability in the nsEventListenerManager::SetEventHandler function in Mozilla Firefox before 25.0, Firefox ESR 17.x before 17.0.10 and 24.x before 24.1, Thunderbird before 24.1, Thunderbird ESR 17.x before 17.0.10, and SeaMonkey before 2.22 allows remote attackers to execute arbitrary code via vectors related to a memory allocation through the garbage collection (GC) API. CVE-2013-5600 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-5600): Use-after-free vulnerability in the nsIOService::NewChannelFromURIWithProxyFlags function in Mozilla Firefox before 25.0, Firefox ESR 17.x before 17.0.10 and 24.x before 24.1, Thunderbird before 24.1, Thunderbird ESR 17.x before 17.0.10, and SeaMonkey before 2.22 allows remote attackers to execute arbitrary code via vectors involving a blob: URL. CVE-2013-5599 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-5599): Use-after-free vulnerability in the nsIPresShell::GetPresContext function in the PresShell (aka presentation shell) implementation in Mozilla Firefox before 25.0, Firefox ESR 17.x before 17.0.10 and 24.x before 24.1, Thunderbird before 24.1, Thunderbird ESR 17.x before 17.0.10, and SeaMonkey before 2.22 allows remote attackers to execute arbitrary code or cause a denial of service (heap memory corruption and application crash) via vectors involving a CANVAS element, a mozTextStyle attribute, and an onresize event. CVE-2013-5598 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-5598): PDF.js in Mozilla Firefox before 25.0 and Firefox ESR 24.x before 24.1 does not properly handle the appending of an IFRAME element, which allows remote attackers to read arbitrary files or execute arbitrary JavaScript code with chrome privileges by using this element within an embedded PDF object. CVE-2013-5597 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-5597): Use-after-free vulnerability in the nsDocLoader::doStopDocumentLoad function in Mozilla Firefox before 25.0, Firefox ESR 17.x before 17.0.10 and 24.x before 24.1, Thunderbird before 24.1, Thunderbird ESR 17.x before 17.0.10, and SeaMonkey before 2.22 allows remote attackers to execute arbitrary code or cause a denial of service (heap memory corruption) via vectors involving a state-change event during an update of the offline cache. CVE-2013-5596 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-5596): The cycle collection (CC) implementation in Mozilla Firefox before 25.0, Firefox ESR 24.x before 24.1, Thunderbird before 24.1, and SeaMonkey before 2.22 does not properly determine the thread for release of an image object, which allows remote attackers to execute arbitrary code or cause a denial of service (race condition and application crash) via a large HTML document containing IMG elements, as demonstrated by the Never-Ending Reddit on reddit.com. CVE-2013-5595 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-5595): The JavaScript engine in Mozilla Firefox before 25.0, Firefox ESR 17.x before 17.0.10 and 24.x before 24.1, Thunderbird before 24.1, Thunderbird ESR 17.x before 17.0.10, and SeaMonkey before 2.22 does not properly allocate memory for unspecified functions, which allows remote attackers to conduct buffer overflow attacks via a crafted web page. CVE-2013-5593 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-5593): The SELECT element implementation in Mozilla Firefox before 25.0, Firefox ESR 24.x before 24.1, Thunderbird before 24.1, and SeaMonkey before 2.22 does not properly restrict the nature or placement of HTML within a dropdown menu, which allows remote attackers to spoof the address bar or conduct clickjacking attacks via vectors that trigger navigation off of a page containing this element. CVE-2013-5592 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-5592): Multiple unspecified vulnerabilities in the browser engine in Mozilla Firefox before 25.0 allow remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via unknown vectors. CVE-2013-5591 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-5591): Unspecified vulnerability in the browser engine in Mozilla Firefox before 25.0, Firefox ESR 24.x before 24.1, Thunderbird before 24.1, and SeaMonkey before 2.22 allows remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via unknown vectors. CVE-2013-5590 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-5590): Multiple unspecified vulnerabilities in the browser engine in Mozilla Firefox before 25.0, Firefox ESR 17.x before 17.0.10 and 24.x before 24.1, Thunderbird before 24.1, Thunderbird ESR 17.x before 17.0.10, and SeaMonkey before 2.22 allow remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via unknown vectors.
In order to stabilize seamonkey-2.22 we need >=media-libs/libpng-1.5.17 stable. Right now 1.5.15 is latest stable version. Unfortunately libpng-1.5.17 ebuild in portage only installes the .so library (SLOT="1.5") and nothing else. So either we can convince libpng maintainers to add a complete libpng-1.5.17 (SLOT="0") ebuild to portage or we need to stabilize libpng-1.6.x. Dunno what's the less painful approach here.
(In reply to Lars Wendler (Polynomial-C) from comment #5) > In order to stabilize seamonkey-2.22 we need >=media-libs/libpng-1.5.17 > stable. Right now 1.5.15 is latest stable version. > Unfortunately libpng-1.5.17 ebuild in portage only installes the .so library > (SLOT="1.5") and nothing else. So either we can convince libpng maintainers > to add a complete libpng-1.5.17 (SLOT="0") ebuild to portage or we need to > stabilize libpng-1.6.x. Dunno what's the less painful approach here. Just a suggestion (without knowing if it's the best thing): If it's a choice between upgrading an insecure package to a newer version to avoid an exploit, and upgrading a dependency package whose newer version may not be stable yet, is it possible to avoid both and just in this case go the Debian route -- patch the vulnerability in the existing version of seamonkey? I don't know what the complications of that would be, so I'm just mentioning the possibility, since it seems like otherwise we're having to choose from two bad options.
How about not using --with-system-png in this version?
(In reply to Brent Busby from comment #6) > Just a suggestion (without knowing if it's the best thing): > > If it's a choice between upgrading an insecure package to a newer version to > avoid an exploit, and upgrading a dependency package whose newer version may > not be stable yet, is it possible to avoid both and just in this case go the > Debian route -- patch the vulnerability in the existing version of > seamonkey? I don't know what the complications of that would be, so I'm > just mentioning the possibility, since it seems like otherwise we're having > to choose from two bad options. Unfortunately I cannot do that kind of backporting work myself because this is way beyond my level of skills. Furthermore it would be a very tedious and thankless work as each and every change since seamonkey-2.21 would have to be analyzed if it's important to one of the above mentioned CVEs or simple development progress which can be left away. (In reply to adr from comment #7) > How about not using --with-system-png in this version? That would violate Gentoo policy which we are already doing way too often in mozilla packages. I am not very attached to that solution. See also https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies I just rememberd that libpng belongs to base-system herd which I recently happen to be a member of. So I added a full working libpng-1.5.17 ebuild myself: +*libpng-1.5.17-r15 (06 Nov 2013) +*libpng-1.5.17-r1 (06 Nov 2013) + + 06 Nov 2013; Lars Wendler <polynomial-c@gentoo.org> -libpng-1.5.17.ebuild, + +libpng-1.5.17-r1.ebuild, +libpng-1.5.17-r15.ebuild: + Added a fully blown 1.5.17 version as it's needed for stabilization of + seamonkey-2.22 (see bug #489796). Moved the SLOT=1.5 ebuild to 1.5.17-r15. +
Any progress here?
(In reply to Stephan Hartmann from comment #9) > Any progress here? Should mozilla herd bring in arches for stabilization itself? we gave go-ahead back on comment #2
(In reply to Ian Stakenvicius from comment #10) > (In reply to Stephan Hartmann from comment #9) > > Any progress here? > > Should mozilla herd bring in arches for stabilization itself? we gave > go-ahead back on comment #2 We will add them soon as we land 24.1.1 firefox.
(In reply to Jory A. Pratt from comment #11) > (In reply to Ian Stakenvicius from comment #10) > > (In reply to Stephan Hartmann from comment #9) > > > Any progress here? > > > > Should mozilla herd bring in arches for stabilization itself? we gave > > go-ahead back on comment #2 > > We will add them soon as we land 24.1.1 firefox. We can bring in the archs, we are going for firefox{-bin}-24.1.1 thunderbird{-bin}-24.1.1 nspr-4.10.2 nss-3.15.4 seamonkey{-bin}-2.22.1, libpng-1.5.17 will also need to be stabilized.
libpng stable is not technically done, but sufficient to allow these keywords. =dev-libs/nspr-4.10.2: Target KEYWORDS="amd64 arm ppc ppc64 x86" =dev-libs/nss-3.15.4: Target KEYWORDS="amd64 arm ppc ppc64 x86" =www-client/firefox-24.1.1: Target KEYWORDS="amd64 arm ppc ppc64 x86" =www-client/firefox-bin-24.1.1: Target KEYWORDS="amd64 x86" =mail-client/thunderbird-24.1.1: Target KEYWORDS="amd64 arm ppc ppc64 x86" =mail-client/thunderbird-bin-24.1.1: Target KEYWORDS="amd64 x86" =www-client/seamonkey-2.22.1: Target KEYWORDS="amd64 x86" =www-client/seamonkey-bin-2.22.1: Target KEYWORDS="amd64 x86" nb for GLSA: nspr/nss + their CVEs (see MFSA 2013-103) should be in summary, but max length reached
Hm, I just noticed bug 491234. And also typo in comment 12. Merge these CVEs into 491234?
amd64 stable
x86 stable
ppc stable
ppc64 stable
arm stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one.
Ping for cleanup, packages been stable for 20 days.
cleaned up as part of bug 491234; sec, please decide whether to glsa this or coalesce into that one.
Arches and Mainter(s), Thank you for your work. Added to an existing GLSA request.
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).
