Firefox 38 has been released yesterday (2015-05-12)
https://www.mozilla.org/en-US/security/advisories/mfsa2015-46 https://www.mozilla.org/en-US/security/advisories/mfsa2015-47 https://www.mozilla.org/en-US/security/advisories/mfsa2015-48 https://www.mozilla.org/en-US/security/advisories/mfsa2015-49 https://www.mozilla.org/en-US/security/advisories/mfsa2015-50 https://www.mozilla.org/en-US/security/advisories/mfsa2015-51 https://www.mozilla.org/en-US/security/advisories/mfsa2015-52 https://www.mozilla.org/en-US/security/advisories/mfsa2015-53 https://www.mozilla.org/en-US/security/advisories/mfsa2015-54 https://www.mozilla.org/en-US/security/advisories/mfsa2015-55 https://www.mozilla.org/en-US/security/advisories/mfsa2015-56 https://www.mozilla.org/en-US/security/advisories/mfsa2015-57 https://www.mozilla.org/en-US/security/advisories/mfsa2015-58
*** Bug 549362 has been marked as a duplicate of this bug. ***
*** Bug 549424 has been marked as a duplicate of this bug. ***
Firefox 38.0.1 released
(In reply to akiraba_honata from comment #4) > Firefox 38.0.1 released https://www.mozilla.org/en-US/firefox/38.0.1/releasenotes/ also, since 38 would need some more time for stabilization: https://www.mozilla.org/en-US/firefox/31.7.0/releasenotes/ Copying the 31.6.0 ebuild to 31.7.0 does work.
Ebuilds for thunderbird{,-bin}-31.7.0, firefox-bin-31.7.0 and firefox-bin-38.0.1 have just been committed to the tree, firefox-31.7.0 will follow shortly and then stabilization efforts can begin. ESR 38.x will likely not be stabilized for at least one more minor version.
All ESR ebuilds in place. Arches, please stabilize as follows: =www-client/firefox-31.7.0 Target KEYWORDS="amd64 hppa ia64 ppc ppc64 x86" =www-client/firefox-bin-31.7.0 Target KEYWORDS="-* amd64 x86" =mail-client/thunderbird-31.7.0 Target KEYWORDS="amd64 ppc ppc64 x86" =mail-client/thunderbird-bin-31.7.0 Target KEYWORDS="-* amd64 x86" The Firefox-38.0 ebuild is still outstanding and will be comitted soon, once mozilla team's fearless leader is back online.
CVE-2015-2718 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-2718): The WebChannel.jsm module in Mozilla Firefox before 38.0 allows remote attackers to bypass the Same Origin Policy and obtain sensitive webchannel-response data via a crafted web site containing an IFRAME element referencing a different web site that is intended to read this data. CVE-2015-2717 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-2717): Integer overflow in libstagefright in Mozilla Firefox before 38.0 allows remote attackers to execute arbitrary code or cause a denial of service (heap-based buffer overflow and out-of-bounds read) via an MP4 video file containing invalid metadata. CVE-2015-2716 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-2716): Buffer overflow in the XML parser in Mozilla Firefox before 38.0, Firefox ESR 31.x before 31.7, and Thunderbird before 31.7 allows remote attackers to execute arbitrary code by providing a large amount of compressed XML data. CVE-2015-2715 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-2715): Race condition in the nsThreadManager::RegisterCurrentThread function in Mozilla Firefox before 38.0 allows remote attackers to execute arbitrary code or cause a denial of service (use-after-free and heap memory corruption) by leveraging improper Media Decoder Thread creation at the time of a shutdown. CVE-2015-2714 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-2714): Mozilla Firefox before 38.0 on Android does not properly restrict writing URL data to the Android logging system, which allows attackers to obtain sensitive information via a crafted application that has a required permission for reading a log, as demonstrated by the READ_LOGS permission for the mixed-content violation log on Android 4.0 and earlier. CVE-2015-2713 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-2713): Use-after-free vulnerability in the SetBreaks function in Mozilla Firefox before 38.0, Firefox ESR 31.x before 31.7, and Thunderbird before 31.7 allows remote attackers to execute arbitrary code or cause a denial of service (heap memory corruption) via a document containing crafted text in conjunction with a Cascading Style Sheets (CSS) token sequence containing properties related to vertical text. CVE-2015-2712 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-2712): The asm.js implementation in Mozilla Firefox before 38.0 does not properly determine heap lengths during identification of cases in which bounds checking may be safely skipped, which allows remote attackers to trigger out-of-bounds write operations and possibly execute arbitrary code, or trigger out-of-bounds read operations and possibly obtain sensitive information from process memory, via crafted JavaScript. CVE-2015-2711 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-2711): Mozilla Firefox before 38.0 does not recognize a referrer policy delivered by a referrer META element in cases of context-menu navigation and middle-click navigation, which allows remote attackers to obtain sensitive information by reading web-server Referer logs that contain private data in a URL, as demonstrated by a private path component. CVE-2015-2710 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-2710): Heap-based buffer overflow in the SVGTextFrame class in Mozilla Firefox before 38.0, Firefox ESR 31.x before 31.7, and Thunderbird before 31.7 allows remote attackers to execute arbitrary code via crafted SVG graphics data in conjunction with a crafted Cascading Style Sheets (CSS) token sequence. CVE-2015-2709 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-2709): Multiple unspecified vulnerabilities in the browser engine in Mozilla Firefox before 38.0 allow remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via unknown vectors. CVE-2015-2708 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-2708): Multiple unspecified vulnerabilities in the browser engine in Mozilla Firefox before 38.0, Firefox ESR 31.x before 31.7, and Thunderbird before 31.7 allow remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via unknown vectors.
Stable for PPC64.
amd64 stable
Stable for HPPA.
x86 stable
I still can not see firefox-38 in tree. As this is a pressuring security issue for many user, i would like to bump this thread.
(In reply to Till Schäfer from comment #13) > I still can not see firefox-38 in tree. As this is a pressuring security > issue for many user, i would like to bump this thread. that is an unstable version and as such not tracked by security
(In reply to Kristian Fiskerstrand from comment #14) > that is an unstable version and as such not tracked by security It is a stable version. Click onto the download link on the website and it will download 38.0.1. The download link on the website only offers the latest stable version. And there is a security issue with earlier versions which is fixed in 38.0.1 as far as I know. At least they are working on a fix. See Logjam.
(In reply to Heiko Baums from comment #15) > (In reply to Kristian Fiskerstrand from comment #14) > > that is an unstable version and as such not tracked by security > > It is a stable version. Click onto the download link on the website and it > will download 38.0.1. The download link on the website only offers the > latest stable version. The current stable in Gentoo is 31 ESR > > And there is a security issue with earlier versions which is fixed in 38.0.1 > as far as I know. At least they are working on a fix. See Logjam. This should also be fixed in 31 ESR
The latest stable upstream version is 38.0.1, and I'm using ~amd86. So the ~amd86 version should be updated, too, to fix this security issue. A security issue doesn't only apply to Gentoo's stable tree. So it would be nice, if firefox would be updated to 38.0.1 anytime soon.
Obviously ~amd64.
+1, please update firefox to 38.0.1
Why was the definition of this bug changed? As reported, this bug is about the Firefox 38 release. Why was it changed to also include the new version of Firefox 31? I guess I can conclude from the fact that this hasn't been done yet that this new release basically requires rewriting the whole ebuild, rite?
(In reply to Ari Entlich from comment #20) > Why was the definition of this bug changed? As reported, this bug is about > the Firefox 38 release. Why was it changed to also include the new version > of Firefox 31? > > I guess I can conclude from the fact that this hasn't been done yet that > this new release basically requires rewriting the whole ebuild, rite? The subject of the bug changed because this is a security bug about the various CVEs listed in the bug, and they need to be addressed on all packages they apply to, not just the latest ~arch firefox. Remember everyone this isn't a "version bump" bug, it's a security bug. Firefox-38 is coming; if you are worried about these vulnerabilities in the meantime then you can run firefox-31.7 or firefox-bin-38.0.1. Also just so that everyone is aware, firefox-31.x will remain the stabilization candidate until -at least- firefox-38.2 is released.
(In reply to Ian Stakenvicius from comment #21) > The subject of the bug changed because this is a security bug about the > various CVEs listed in the bug, and they need to be addressed on all > packages they apply to, not just the latest ~arch firefox. Remember > everyone this isn't a "version bump" bug, it's a security bug. And because it's a security bug, and at least one of the security issues with firefox < 38.0.1 is fixed in 38.0.1, firefox needs to be updated in the portage tree urgently. And, btw., the version bump bug 549424 was closed as duplicate of this bug report. If you think, that this bug report is only a security bug and not a version bump bug, then you should reopen bug 549424. Nevertheless in my opinion it doesn't matter if firefox gets updated because of a security or a version bump bug report, because it's both a version bump and a fix of a not so trivial security issue called Logjam. So, please, update firefox instead of coming up with excuses. > Firefox-38 is coming; if you are worried about these vulnerabilities in the > meantime then you can run firefox-31.7 or firefox-bin-38.0.1. firefox-bin is not an option for users of firefox, because there are a few incompatibilities between firefox and firefox-bin.
(In reply to Ian Stakenvicius from comment #21) > The subject of the bug changed because this is a security bug about the > various CVEs listed in the bug, and they need to be addressed on all > packages they apply to, not just the latest ~arch firefox. Remember > everyone this isn't a "version bump" bug, it's a security bug. And yet it is not being treated as a security bug. The 31.7 version bump was handled within a couple days, and the 38 version bump has now taken almost two weeks and counting. So which is it? Is this a security bug or not? In comment #7, you assured everyone that the Firefox 38 ebuild would be added "once mozilla team's fearless leader is back online". Are none of the five other members of the mozilla team[1] able to perform this simple version bump? 1. As listed here: https://wiki.gentoo.org/wiki/Project:Mozilla
Guys, this bug was already converted to security bug and assigned to security@ team. As they usually deal with security issues in *stable* packages, I urge you to move the discussion to a more relevant bug 550424.
(In reply to Alexander Tsoy from comment #24) > Guys, this bug was already converted to security bug and assigned to > security@ team. As they usually deal with security issues in *stable* > packages, I urge you to move the discussion to a more relevant bug 550424. What are you talking about? Multiple people have explicitly said that Firefox 38 is included in this bug. It's included in the title. If they didn't want this bug to include Firefox 38, they should have said so. That would have been pretty ridiculous however, considering that this bug was created to be about Firefox 38. However, bug 550424 is also extremely relevant in a general sense.
(In reply to Alexander Tsoy from comment #24) > Guys, this bug was already converted to security bug and assigned to > security@ team. As they usually deal with security issues in *stable* > packages, I urge you to move the discussion to a more relevant bug 550424. And bug 550424 is actually a duplicate of bug 549424 which itself is closed as duplicate of this bug report. So I guess someone should clean those bugs and reopen bug 549424, close bug 550424 as duplicate of bug 549424, if it is not to be handled as a duplicate of this bug.
(In reply to Ari Entlich from comment #25) > (In reply to Alexander Tsoy from comment #24) > > Guys, this bug was already converted to security bug and assigned to > > security@ team. As they usually deal with security issues in *stable* > > packages, I urge you to move the discussion to a more relevant bug 550424. > > What are you talking about? [...] Alexander's point here is that because this is a security bug, commentary should be limited here to security related issues, not general chatter about version bumping. Now back to the point in hand -- firefox-38.0.1 has been committed to the main tree. There are still no seamonkey versions available from upstream with the necessary fixes. I don't know what security wants to do about that.
(In reply to Ian Stakenvicius from comment #27) > Alexander's point here is that because this is a security bug, commentary > should be limited here to security related issues, not general chatter about > version bumping. Version bumping is/was security related in this case. > Now back to the point in hand -- firefox-38.0.1 has been committed to the > main tree. I don't see it (yet) in the portage tree, but maybe mirrors aren't synced yet.
(In reply to Ian Stakenvicius from comment #27) > (In reply to Ari Entlich from comment #25) > > (In reply to Alexander Tsoy from comment #24) > > > Guys, this bug was already converted to security bug and assigned to > > > security@ team. As they usually deal with security issues in *stable* > > > packages, I urge you to move the discussion to a more relevant bug 550424. > > > > What are you talking about? [...] > > Alexander's point here is that because this is a security bug, commentary > should be limited here to security related issues, not general chatter about > version bumping. > > > Now back to the point in hand -- firefox-38.0.1 has been committed to the > main tree. > > There are still no seamonkey versions available from upstream with the > necessary fixes. I don't know what security wants to do about that. there was no commit by now... see https://packages.gentoo.org/package/www-client/firefox
https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-client/firefox/firefox-38.0.1.ebuild?view=markup
It seems to be a synchronization problem with (some/all ?) Gentoo mirrors. For a few hours only metadata/timestamp.chk get updated, So it looks like a Gentoo Infrastructure problem. Timestamp of repository gentoo: Wed, 27 May 2015 23:00:01 +0000 ls -l /usr/portage/www-client/firefox total 493 -rw-r--r-- 1 root root 68673 May 23 21:31 ChangeLog -rw-r--r-- 1 root root 109736 Jan 2 2012 ChangeLog-2009 -rw-r--r-- 1 root root 229461 May 23 21:31 Manifest drwxr-xr-x 3 root root 536 Apr 7 08:50 files -rw-r--r-- 1 root root 12084 Feb 26 23:01 firefox-24.3.0.ebuild -rw-r--r-- 1 root root 11618 Mar 27 10:31 firefox-31.5.3.ebuild -rw-r--r-- 1 root root 11619 Apr 29 11:31 firefox-31.6.0.ebuild -rw-r--r-- 1 root root 11624 May 23 21:31 firefox-31.7.0.ebuild -rw-r--r-- 1 root root 11783 Mar 24 09:53 firefox-36.0.4.ebuild -rw-r--r-- 1 root root 11716 Apr 7 01:01 firefox-37.0.1.ebuild -rw-r--r-- 1 root root 11725 Apr 23 15:14 firefox-37.0.2.ebuild -rw-r--r-- 1 root root 1332 Feb 26 23:01 metadata.xml
ppc stable
Ping on ia64 stabilization.
Arches and Maintainer(s), Thank you for your work. Added to an existing GLSA Request.
This issue was resolved and addressed in GLSA 201605-06 at https://security.gentoo.org/glsa/201605-06 by GLSA coordinator Yury German (BlueKnight).
