Closed Bug 866850 Opened 12 years ago Closed 11 years ago

Firefox installs an old msvcr100.dll and msvcp100.dll (with known vulnerabilities but not in Mozilla usage)

Categories

(Firefox Build System :: General, defect)

Product:
Firefox Build System
Component:
General
Version:
20 Branch
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: stefan.kanthak, Unassigned)

References

Details

User Agent: Opera/9.80 (Windows NT 5.0; U; de) Presto/2.10.289 Version/12.02 Steps to reproduce: Install Firefox Actual results: Firefox installs VULNERABLE and outdated MSVCRT libraries msvcr100.dll and msvcp100.dll version 10.0.30319.1 in its application directory. See http://support.microsoft.com/kb/2467173 resp. http://www.microsoft.com/technet/security/bulletin/MS11-025.mspx Expected results: Firefox MUST NOT install private copies of the MSVCRT libraries, but use the redistributable package instead. See http://support.microsoft.com/kb/835322
Severity: normal → critical
OS: Windows 2000 → All
We are not going to stop shipping private copies of the MSVC libraries, because doing so would break unprivileged install as well as single-directory install via ZIP file. As far as I can tell, this advisory does not affect Firefox. From the article: * Your application makes use of the Microsoft Foundation Class (MFC) Library * Your application allows the loading of dynamic link libraries from untrusted locations, such as WebDAV shares Neither of these conditions applies to Firefox. So while I do believe we should update our build farm to provide the newer version of the VC redistributables, I don't think this bug needs to remain private, nor is it an urgent security issue. robstrong, do you agree?
Status: UNCONFIRMED → NEW
Component: Untriaged → Build Config
Ever confirmed: true
Flags: needinfo?(robert.bugzilla)
Agreed. Note: the security team has discussed making it a requirement to only allow installs when admin from the installer about a year ago but this wouldn't handle the ZIP file case.
Flags: needinfo?(robert.bugzilla)
Why would we do that? Non-admin installs are an important feature for a bunch of people working on locked-down computers. In any case, I'm going to open this up, but perhaps it should be a releng bug instead of build-config since it almost certainly involves a patch update to the build slaves. joduinn, do you have a preference how to handle that?
Group: core-security
Flags: needinfo?(joduinn)
Summary: Firefox installs VULNERABLE msvcr100.dll and msvcp100.dll → Firefox installs an old msvcr100.dll and msvcp100.dll (with known vulnerabilities but not in Mozilla usage)
(In reply to Benjamin Smedberg [:bsmedberg] from comment #3) > Why would we do that? Non-admin installs are an important feature for a > bunch of people working on locked-down computers. It is a give (less users) and take (increased security)... it is easier to add security measures when installing as admin. For example, with admin we could be assured of using the maintenance service for updates which allows us to use a protected location for many of the required tasks.
I'm not sure how the DLL loading works anymore. For Visual C++ 2005 and 2008 the CRT DLLs were all SxS-setup, which meant that if there was a newer version installed on the system you'd get that loaded instead. With 2010 they're no longer SxS, so I guess we just wind up loading our local copies all the time? In any event, if it's only MFC then it doesn't really matter.
1. IFF you ship 3rd party DLLs, then ship their current version, not a superseded version. Do you know for sure that MSFT did not fix other (unpublished) security holes? 2. If you install with administrative privileges and/or for all users, then install the (current) MSVCRT redistributable. This will get updated via Windows Update, so you dont have to care. 3. Private (or portable) installations (in user-writable locations) are BAD (in my eyes a REALLY stupid idea), they circumvent the primary security boundary not only on Windows: %SystemRoot% and %ProgramFiles% are not writable by the ordinary user.
(In reply to Stefan Kanthak from comment #6) > 3. Private (or portable) installations (in user-writable locations) are BAD > (in my eyes a REALLY stupid idea), they circumvent the primary security > boundary not only on Windows: %SystemRoot% and %ProgramFiles% are not > writable by the ordinary user. This makes zero sense. Any security issues caused by someone having write access to the Firefox application directory aren't changed one bit by us putting the CRT there. If we didn't have them there, someone could simply put their own copy there to force us to use them.
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #7) > (In reply to Stefan Kanthak from comment #6) >> 3. Private (or portable) installations (in user-writable locations) are BAD >> (in my eyes a REALLY stupid idea), they circumvent the primary security >> boundary not only on Windows: %SystemRoot% and %ProgramFiles% are not >> writable by the ordinary user. > > This makes zero sense. Any security issues caused by someone having write > access to the Firefox application directory aren't changed one bit by us > putting the CRT there. If we didn't have them there, someone could simply > put their own copy there to force us to use them. Read again what I wrote, carefully, and TRY to understand it! In comment #1 Benjamin Smedberg wrote: | We are not going to stop shipping private copies of the MSVC | libraries, because doing so would break unprivileged install | as well as single-directory install via ZIP file.
(In reply to Benjamin Smedberg [:bsmedberg] from comment #1) > We are not going to stop shipping private copies of the MSVC libraries, > because doing so would break unprivileged install as well as > single-directory install via ZIP file. Ouch.-( See http://support.microsoft.com/kb/835322 > As far as I can tell, this advisory does not affect Firefox. From the > article: > > * Your application makes use of the Microsoft Foundation Class (MFC) Library > * Your application allows the loading of dynamic link libraries from > untrusted locations, such as WebDAV shares > > Neither of these conditions applies to Firefox. Is it possible to write an add-on or extension which uses MFC or allows loading of DLLs from untrusted locations? If yes: gotcha! > So while I do believe we > should update our build farm to provide the newer version of the VC > redistributables, Right. That's the first thing to do. I wonder why you dont keep your build farm uptodate. > I don't think this bug needs to remain private, nor is it > an urgent security issue. > > robstrong, do you agree?
(In reply to Stefan Kanthak from comment #9) > Right. That's the first thing to do. > I wonder why you dont keep your build farm uptodate. Because we have a lot of experience with updating toolchains, and things frequently break. We typically only update our toolchain when doing so provides something of value. I still don't think this qualifies. I'd rather spend the effort to update to Visual C++ 2012 instead.
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #10) > (In reply to Stefan Kanthak from comment #9) >> Right. That's the first thing to do. >> I wonder why you dont keep your build farm uptodate. > > Because we have a lot of experience with updating toolchains, and things > frequently break. If an update of the MSVCRT breaks your (well-written.-) application, you can blame MSFT and request them to fix their incompatible change in the MSVCRT. JFTR: dont you use the current (and patched) version of Visual C++ 2010 on your build farm? If yes, you already have the current MSVCRT installed and link against it. Why dont you include the MSVCRT you link against in Mozilla? If not: please stay away from ANY software production environment! > We typically only update our toolchain when doing so > provides something of value. Security fixes have no value? > I still don't think this qualifies. I'd rather > spend the effort to update to Visual C++ 2012 instead. MSFT publishes updates and security fixes for Visual C++ 2012 too!
there is more to it then just security there is also performance gains from updating it
We switched to Visual C++ 2013.
Status: NEW → RESOLVED
Closed: 11 years ago
Depends on: 1061335
Flags: needinfo?(john+bugzilla)
Resolution: --- → FIXED
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #13) > We switched to Visual C++ 2013. ... and continue to make the exact same beginner's error there: the MSVC?120.DLL (version 12.0.21005.1, dated 2013-10-05) shipped with Mozilla products are completely outdated. Several more recent versions are available, see for example <https://support.microsoft.com/en-us/kb/3138367> and <https://support.microsoft.com/en-us/kb/3179560> To make things worse, these outdated DLLs are installed into a private location, the installation directory of Mozilla, instead Windows' system directory, where these DLL belong! This BAD practice is against Microsoft's guidelines and recommendations, see for example <https://support.microsoft.com/en-us/kb/835322> and <https://msdn.microsoft.com/en-us/library/ms235299.aspx> | For servicing reasons, we do not recommend that you use this | [application local folder] installation location. ... | We recommend that you use this [Visual C++ Redistributable] | package to redistribute Visual C++ libraries for applications | that you build. Why does Mozilla ignore these guidelines and recommendations?
Status: RESOLVED → VERIFIED
Flags: needinfo?(ted)
Because we don't require Administrator privileges to install Firefox.
Flags: needinfo?(ted)
I don't know what version of Firefox you're looking at, we've since switched to Visual C++ 2015. In any event, we're unlikely to ever change our behavior here.
For the record, Firefox Nightly 52 is shipping with msvcp140.dll, version 14.0.24210.0.
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #16) > I don't know what version of Firefox you're looking at, Ain't you able to check which versions of Firefox are still built with MSVC 2012? Hint: they have ESR in their name. > we've since switched to Visual C++ 2015. In any event, we're unlikely to ever change our behavior here. Other people learn from their mistakes!
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #15) > Because we don't require Administrator privileges to install Firefox. So you violate one of the MINIMUM requirements of Microsoft's more than 20 year old "Designed for Windows" guidelines: programs have to be installed in %ProgramFiles% (where they are protected against tampering by unprivileged users). (In reply to Ted Mielczarek [:ted.mielczarek] from comment #16) > I don't know what version of Firefox you're looking at, Ain't you able to check which versions of Firefox are still built with MSVC 2012? Hint: they have ESR in their name. > we've since switched to Visual C++ 2015. Microsoft's recommendation is valid for ALL versions of their VC++ runtime! > In any event, we're unlikely to ever change our behavior here. Other people learn from their mistakes!
Please stop commenting in this bug. You have made your opinion known. You are free to use other software, or build your own copy of Firefox.
Component: Build Config → General
Product: Firefox → Firefox Build System
You need to log in before you can comment on or make changes to this bug.