Closed Bug 522777 Opened 15 years ago Closed 15 years ago

Blocklist "Windows Presentation Foundation" plugin (installed automatically via .NET Framework 3.5 SP1 update)

Categories

(Toolkit :: Blocklist Policy Requests, defect)

Product:
Toolkit
Component:
Blocklist Policy Requests
Platform:
All
Windows XP
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: chofmann, Assigned: morgamic)

References

(
URL
)

Details

(Whiteboard: [see comment 56 & 83])

Attachments

(2 files, 1 obsolete file)

v1, can someone verify
2.24 KB, text/xml
Details
v2 query
306 bytes, text/plain
Details
asa found this http://www.computerworld.com/s/article/9139459/Sneaky_Microsoft_plug_in_puts_Firefox_users_at_risk searches also turn up problems with crashing after this plugin is slipped into firefox installs. we need to dig up names and versions of the .dlls and figure out how to block.
http://forums.mozillazine.org/viewtopic.php?f=40&t=1357655 says the name is NPWPF.dll http://alexle.net/archives/tag/windows-presentation-foundation talks about crashing firefox following an update back last summer.
I don't seem to find any crashes with NPWPF.dll in the signature so any crash must be happening in other code
that .dll doesn't seem to turn up in dbaron's list either http://people.mozilla.org/~dbaron/crash-stats/20090929-interesting-modules
OS: All → Windows XP
Hardware: x86 → All
http://support.mozilla.com/tiki-view_forum_thread.php?locale=fr&comments_parentId=451702&forumId=1 also says disabling the plugin improves performance for users seeing slowdowns.
there are some removal instructions at http://support.microsoft.com/?kbid=963707
http://blogs.zdnet.com/security/?p=4614&tag=trunk;content is more about it; it says that Microsoft is recommending that users disable it. (Is there also a Microsoft page that says so?) It does show up in http://people.mozilla.org/~dbaron/crash-stats/20090929-interesting-addons , although the correlations that show up aren't necessarily signs of causation. However, that shows that it's quite common in the wild: it's installed for the users submitting 48% of our Windows crash reports on Firefox 3.5.3. The GUID is "{20a82645-c095-46ed-80e3-08825760534b}" if we want to block it. If Microsoft is recommending disabling it (all versions, or just some?) because of security vulnerabilities, then I'd strongly support adding it to the blocklist.
(In reply to comment #6) > The GUID is "{20a82645-c095-46ed-80e3-08825760534b}" if we want to block it. > > If Microsoft is recommending disabling it (all versions, or just some?) because > of security vulnerabilities, then I'd strongly support adding it to the > blocklist. Yes, please.
(In reply to comment #6) > The GUID is "{20a82645-c095-46ed-80e3-08825760534b}" if we want to block it. That's for the "Microsoft .NET Framework Assistant" extension. The "Windows Presentation Foundation" mentioned above is a plugin. Do we want to block them both?
Assignee: nobody → morgamic
Severity: normal → blocker
Status: NEW → ASSIGNED
I think we should block: {20a82645-c095-46ed-80e3-08825760534b} (extension GUID) NPWPF.dll (plugin file) We can remove it later if we have to.
Or should we do on name="Windows Presentation Foundation.*"
(In reply to comment #10) > Or should we do on name="Windows Presentation Foundation.*" Name or name plus filename sounds better than just filename. NPWPF.dll is kinda cryptic and short so it might be good to be specific.
Attached file v1, can someone verify —
blocks guid and the plugin name
Attached file query (obsolete) —
Attached file v2 query —
err, this time without bad dates.
Attachment #406816 - Attachment is obsolete: true
The add-on with the above GUID is also on AMO @ https://addons.mozilla.org/en-US/firefox/addon/9449
Alright, I'm satisfied with the query; we'll push it and if you guys find problems we'll figure it out later. Should we disable the add-on on AMO? Do they have a fix?
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
It'd be fairly awkward to continue to list a banned extension on AMO.
Add-on entry was disabled.
Status: RESOLVED → VERIFIED
I installed the .NET Framework 3.5 SP1 from http://msdn.microsoft.com/en-us/netframework/aa569263.aspx into a WinXP SP3 VM and then forced a Firefox banlist update. Both now show as "Disabled for your protection", however initially it only told me in the popup notification that the plugin was a problem, not the extension. The web page also needs a line for this now: https://www.mozilla.com/en-US/blocklist/ Kudos for the fast ban, by the way.
How does the blocklist get propagated to the end-user ? Sorry for the question, but I'm not having any luck finding out how it works.
(In reply to comment #21) > How does the blocklist get propagated to the end-user ? Sorry for the > question, but I'm not having any luck finding out how it works. It's updated automatically on an interval. See the various extensions.blocklist.* prefs in about:config. A quick way to force an update is by running the following from the code execution field in the error console: Components.classes['@mozilla.org/extensions/blocklist;1'].getService(Components.interfaces.nsITimerCallback).notify(null)
http://blogs.technet.com/srd/archive/2009/10/12/ms09-054.aspx is the Microsoft article about this, from Monday. For the web page blurb: Reason: remote code execution vulnerability
Summary: blocklist evil versions of microsoft .NET Framework Assistant [the name of the add-on slipped into Firefox] → blocklist all versions of microsoft .NET Framework Assistant [the name of the add-on slipped into Firefox]
URL: http://blogs.technet.com/srd/archive/...
Summary: blocklist all versions of microsoft .NET Framework Assistant [the name of the add-on slipped into Firefox] → Blocklist all versions of "Microsoft .NET Framework Assistant" extension and associated "Windows Presentation Foundation" plugin (installed automatically via .NET Framework 3.5 SP1 update)
I got the message for blocking this add-on, if you click for more information, it redirects here: https://www.mozilla.com/en-US/blocklist/ As far as I see, there is no relevant information there about it.
Yes, was noted in comment 20 and the text to add was in comment 23 just above. Just needs to be put up by someone now.
I'm getting this landed on mozilla.com now.
I think this is right, but if it's not, we can fix it later (and having a bug on the page is better than no bug). After sanity-checking with Mossop and having him correct me, I'm adding this: <li>Microsoft .NET Framework Assistant and Windows Presentation Foundation, all versions, for all applications. Reason: remote code execution vulnerability (<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=522777">see bug 522777</a>).</li>
Landed on trunk, stage, and production in SVN directly. Should be live in a few minutes.
It's now on production behind the cache. As soon as the cache clears, users will see it.
Went to eat dinner -- thanks for doing that, Sam.
Depends on: 522851
Why was the .NET framework assistant blocked? From what I understand from reading <http://blogs.technet.com/srd/archive/2009/10/12/ms09-054.aspx>, the vulnerability is only in an older version of NPWPF.dll. I can't find a source for Microsoft recommending disabling it.
Is there a particular reason why these are being blocked two days after Microsoft released a fix for this issue? MS09-054 was released on 10/14/2009, which the linked technet article in comment #23 very clearly states resolves this issue for both IE and Firefox. Personally, the only time an extension or addon should ever be blocked is for an unpatched vulnerability. Even then, there should be some way for me to override this if I choose to, which there doesn't appear to be from what I can see.
(In reply to comment #32) > Is there a particular reason why these are being blocked two days after > Microsoft released a fix for this issue? > > MS09-054 was released on 10/14/2009, which the linked technet article in > comment #23 very clearly states resolves this issue for both IE and Firefox. > > Personally, the only time an extension or addon should ever be blocked is for > an unpatched vulnerability. Even then, there should be some way for me to > override this if I choose to, which there doesn't appear to be from what I can > see. See bug 522851.
Agree with comments 31 and 32. The vulnerability is only present in older versions of the framework, therefore we should not be blocking the plugin which is, AFAICT, unchanged by the patch. Note that list of changed files is here <http://support.microsoft.com/kb/974455> and npwpf.dll is not among them, which suggests the vulnerability is not in the plugin but in the OS... should we block firefox from working on buggy OSs?
The "more information" link for the block doesn't work. It directs to a page on https://en-gb.www.mozilla.com/ which has an invalid ssl cert.
Yeah I don't see why this is blocked at all; the problem really isn't with the WPF plugin itself but rather part of the Windows operating system. A more helpful thing to do would be to check if KB974455 is installed first, rather than unilaterally blocking the addon (which actually has legitimate uses: Google Chrome is installed with ClickOnce, etc). Blocking the addon (and creating the intimidating "blocked addons" dialog) is likely to spread the so-called "fud" As a side note, the "blocked addons" dialog seems to have problems; the browser popup spawned by the "more information" seemed to prevent me from clicking on the blocked addons dialog itself and instead forcing focus on the popped up window.
If this isn't going to be reversed, I'd like to propose only blocking wpf for Firefox 3.5.3 and lower. As far as I can tell, there's currently no way for Firefox to detect which Windows Updates are installed through the blocklist (as the problem stems not with the plugin but an OS component), so until 3.5.4 fixes that, this would probably be the better solution than blocking wpf for all versions past and present.
Thank you for making my company's products no longer functional under FireFox. What were you thinking? I hope you get your head straight before Monday morning or my help desk phone will be ringing off the wall.
I don't suspect they realised this would also apply to machines with the fix installed.
Also, do we know who at MS recommended this, and how official the recommendation is? It strikes me as bizarre that they would request we permanently disable an application they went to some effort to ensure was widely installed.
This all would not be an issue if MS would provide a version number for the used plugin and the addon. Mozilla could only block affected plugin + addon versions and MS could raise the version number after a security update.
Matthias: This wouldn't have helped anything, since the component affected is not the plugin
But what if I trust a site, and need to have those features enabled to view content there? It was automatically blocked by firefox. I hope I can figure out a way to unblock it.
Re: comment #44 - you could try changing pref extensions.blocklist.enabled to false, at which point you should be able to reenable the extensions in question. Re: comment #42 - neither the plugin nor the extension are updated by the hotfix, only an OS component that they depend upon is changed. All versions of the extension or plugin are affected if the old version of the system component is installed, none are affected if the new version is installed. Firefox doesn't contain a mechanism for checking system library versions, so there's no way to automatically block the plugin only on affected systems. It's all or nothing: we disable this functionality completely, or we let it be even on systems with the vulnerability. As the vulnerability is not ours, I strongly suggest the latter is better than losing functionality that previously worked.
Just for clarities sake, my proposed solution to this issue is as follows: - remove the extension and plugin from the blocklist - as a matter of priority, update the blocklist mechanism so that a block can be made that depends on versions of installed system libraries - release said updated mechanism as a critical firefox update, and reinstate the block only for systems with the old versions. People who do not update to the new firefox version should continue being able to use the plugin. The general principles I feel are important here are: - Working functionality should never be removed from an installed browser, unless the user chooses to have that functionality removed (e.g. by installing an update) - Updates should be provided as quickly as possible to enable people to secure their systems as well as possible.
Is the framework version changed by the update? If so, we should be able to detect it in the user agent. Is it possible to serve a different blocklist to differing user agents?
If the extension has been blocked, the framework version won't be reported in the user agent. Not sure how this will affect any such resolution?
(In reply to comment #46) > Just for clarities sake, my proposed solution to this issue is as follows: > > - remove the extension and plugin from the blocklist > - as a matter of priority, update the blocklist mechanism so that a block can > be made that depends on versions of installed system libraries > - release said updated mechanism as a critical firefox update, and reinstate > the block only for systems with the old versions. People who do not update to > the new firefox version should continue being able to use the plugin. That doesn't seem likely to me. The add-on blocklist, fundamentally, blocks insecure/unstable add-ons. The blocked add-on versions use insecure OS components and are thus insecure. Just because the add-on versions for some people could use components that are supposedly secured does not change the fact that they also can use insecure ones. This is not a system library blocklist. If explicitly labeled versions that are not potentially vulnerable are to be released then those should be opened up. > The general principles I feel are important here are: > > - Working functionality should never be removed from an installed browser, > unless the user chooses to have that functionality removed (e.g. by installing > an update) > - Updates should be provided as quickly as possible to enable people to secure > their systems as well as possible. True, but the later overrules the former. (In reply to comment #47) > Is the framework version changed by the update? If so, we should be able to > detect it in the user agent. > > Is it possible to serve a different blocklist to differing user agents? Again, no.
The extension shouldn't be blocked anyway - the [WPF] plugin is the vector, not ClickOnce [extension]. What happens if an item is removed from the blocklist? Is it re-enabled?
> The blocked add-on versions use insecure OS components and are thus insecure. Firefox uses the Explorer shell for its filepicker. By your logic, if a security bug is found and patched in the Explorer shell, Firefox should stop using it altogether. Note that this is a vulnerability for which a patch has already been released. People that received Tuesday's updates are secure even without the plugin disabled.
Could it at least be a soft-blocked (as added in bug 455906)? Otherwise websites (and sysadmins') will probable start disabling the blocklist mechanism entirely (as they have no choice) - completely defeating the purpose.
You can see the plugin/addon and the framework as one unit, you can compare that as example with the Java plugin and the Java virtual machine. Both contain the same version number and if the JVM gets a security fix, the plugin version number will be changed as well. What's making this worse is that MS installs this addon/plugin not as opt-in or opt-out component, they install it without asking and you can only choose to uninstall it later like many malware while an opt-in install would be the only fair solution. Many users didn't notice this installation and MS got enough bad press about this and blocking the plugin is the only right solution to protect such users that didn't notice this in the back installation. Firefox doesn't need to check system libarys, they don't matter, only installed NPAPI Plugins and Addons. If Firefox calls system functions itself then we would have to fix it on our side as Mozilla.org already did in the past. The blocklist is by design something that helps Mozilla.org to protect Gecko users from something that is outside of Mozilla.org control (Plugins/addons). BTW: The plugin is blocked by Seamonkey as well, thanks morgamic !
(In reply to comment #52) > Could it at least be a soft-blocked (as added in bug 455906)? > > Otherwise websites (and sysadmins') will probable start disabling the blocklist > mechanism entirely (as they have no choice) - completely defeating the purpose. Good point and idea, but not currently applicable. Soft blocking is only implemented on the client side at this point. (bug 462433)
(In reply to comment #53) > You can see the plugin/addon and the framework as one unit ... the plugin version number will be changed as well. You could think of it that way, but it's not be a useful thing to do because it is just not true in this case. The plugin version has not changed because there is no bug in the plugin. (In reply to comment #54) > Soft blocking is only implemented on the client side at this point. Ah, that's a shame. Bug 462433 doesn't seem to be going anywhere real fast.
I spoke on the phone with the responsible director at Microsoft on Friday, and she agreed that the blocklist was the right approach. We can evaluate changes to the blocklist in the future, and updates take effect quite quickly, but right now both Microsoft and Mozilla are in agreement that this is the best way to protect our mutual users. It's important to note that the vast majority of users with this add-on installed did not know that it was installed, or ask for it to be installed, and it's very difficult to uninstall cleanly due to the hidden extension that is left behind, as well as the "9.*.*" maxversion. This means that users who don't normally care about IE updates, because they are Firefox users, will be vulnerable until it is available to them and installed. Using Firefox while evaluating an IE security patch for deployment is an entirely reasonable approach, which is why we contacted Microsoft with the blocklist plan. (I can't speak to Microsoft's reasoning, but they certainly agreed with the plan.) The add-on is also not available in Windows 7, and I believe is uninstalled as part of upgrades from Vista or XP to that operating system, which I think indicates that Microsoft does not plan for this to be available in its current form long-term. I will see if I can get someone from Microsoft to comment on their plans, and if we can make an unblocked (and cleaned-up) version of the add-on available for the fraction of users who actively want to install that capability, and can therefore be made aware of the additional attack surface it represents.
http://blog.mozilla.com/security/2009/10/16/net-framework-assistant-blocked-to-disarm-security-vulnerability/ If Microsoft agreed to block "Microsoft .NET Framework Assistant", but not agreed to Windows Presentation Foundation plug-in? Two extension/plugin is not associated.
Whiteboard: [see comment 56]
(In reply to comment #56) > The add-on is also not available in Windows 7, and I believe is uninstalled as > part of upgrades from Vista or XP to that operating system, which I think > indicates that Microsoft does not plan for this to be available in its current > form long-term. I will see if I can get someone from Microsoft to comment on > their plans, and if we can make an unblocked (and cleaned-up) version of the > add-on available for the fraction of users who actively want to install that > capability, and can therefore be made aware of the additional attack surface it > represents. Really? That's interesting since all my machines are running Windows 7 and I have the plugin installed. I'm sorry, but I still disagree with this block. Were the problem unpatched, then I could agree with it. But you're blocking a PATCHED vulnerability! People who aren't installing their operating system patches automatically or regularly are likely vulnerable to all sorts of things. Users who are automatically receiving windows updates received the patch for this issue *2 days* before this block was put out. In fact, the Computerworld article linked in the description of this bug states, "This week, Microsoft did not revisit the origin of the .NET add-on, but simply told Firefox users that they should uninstall the component if they weren't able to deploy the patches provided in the MS09-054 update." Very clearly, ONLY if you are not going to deploy MS09-054 should you block the add-on. Since MS09-054 was deployed as part of Patch Tuesday on 14 October 2009, automatically pushed via Windows Update as an Important update.
(In reply to comment #57) > Two extension/plugin is not associated. They're both installed automatically with .NET Framework 3.5 SP1. (In reply to comment #55) > The plugin version has not changed because there > is no bug in the plugin. This misunderstanding started up in the 30-something comments above. Potentially vulnerable is the same thing as vulnerable. The plugin effectively changed with the update by virtue of whatever component it uses being changed. If it wants to be treated as safe then it'd better be explicitly different from the unsafe case. (In reply to comment #58) > I'm sorry, but I still disagree with this block. Were the problem unpatched, > then I could agree with it. But you're blocking a PATCHED vulnerability! We are blocking the unpatched vulnerability. It's just that there's no appreciable difference between the patched and unpatched versions (as previously noted up in comment 42) so it's all blocked at once. As stated in comment 56, Firefox users are by no means guaranteed to have both the update that caused this and the update that fixed this. > Very clearly, ONLY if you are not going to deploy MS09-054 should you block the > add-on. Since MS09-054 was deployed as part of Patch Tuesday on 14 October > 2009, automatically pushed via Windows Update as an Important update. Mozilla should not be relying on IE updates for security.
I also ran into the problem Julian Hall described in comment 35, I have filed it as bug 522894.
Depends on: 505031
(In reply to comment #60) > I also ran into the problem Julian Hall described in comment 35, I have filed > it as bug 522894. Yeah, that's bug 505031. Marked this as dependent on that seeing as lots of people are hitting it due to this now. Hopefully that can be fixed quickly.
(In reply to comment #59) > We are blocking the unpatched vulnerability. It's just that there's no > appreciable difference between the patched and unpatched versions (as > previously noted up in comment 42) so it's all blocked at once. As stated in > comment 56, Firefox users are by no means guaranteed to have both the update > that caused this and the update that fixed this. > > > Very clearly, ONLY if you are not going to deploy MS09-054 should you block the > > add-on. Since MS09-054 was deployed as part of Patch Tuesday on 14 October > > 2009, automatically pushed via Windows Update as an Important update. > > Mozilla should not be relying on IE updates for security. So by that logic this add-on will never be unblocked then, since it has been stated earlier that there's no way to tell whether the update has been installed. Seems like a pretty sneaky way to permanently disable an add-on that many people have found controversial. I still don't agree with this. If Firefox itself used a Windows library for, say, viewing images, that was found to have a vulnerability and was then patched, would you say that image support should be disabled in Firefox because someone might not have installed the patch for the library? Had this vulnerability been reported a couple of weeks ago and there was no patch, then I would completely agree with blocking it. Once the patch was released, though, there is absolutely no reason to have this blocked.
I don't understand. The OS has (correction: "had") a security vulnerability, not the add-ons and not FireFox, AND the OS provider has already deployed a fix (2 days prior to Mozilla breaking this important functionality), so why is Mozilla taking any action at all? Additionally, now that Mozilla HAS intentionally disabled this important functionality, has anyone considered what the ultimate solution is and when it will be available? Click-Once deployment is an incredibly important technology to both me personally and to the company I work for, including all of our customers (tens of thousands internally) and many externally as well. What's the solution for TODAY??? How or WHEN are our FireFox users supposed to be able to launch our business critical software? I commend your developers for jumping into action so rapidly, but I think you guys were way too trigger happy on this one. You should NOT disable this feature for users that are NOT vulnerable. At the very least, we need a way to manually re-enable these add-ons. Like I said, we've got business-critical applications that depend on these add-ons. Like someone commented above, if there's a vulnerability found in the shell components that the "Save As" dialog box uses, do you disable that as well? Critically, what's your plan for a fix and how soon will it be on my user's machines?
(In reply to comment #62) > So by that logic this add-on will never be unblocked then, since it has been > stated earlier that there's no way to tell whether the update has been > installed. Clearly, that ability needs to be added in said update. The plugin needs to correctly report a new version number to indicate that it can't be using the old vulnerability. (no maybes allowed here) > I still don't agree with this. If Firefox itself used a Windows library for, > say, viewing images, that was found to have a vulnerability and was then > patched, would you say that image support should be disabled in Firefox because > someone might not have installed the patch for the library? It'd be a security risk to be at the mercy of some external library like that. That's basically what happened here. The thing that some of you aren't understanding is that these supposedly absurd cases all really would end in a "yes". If it's a (potential) vulnerability it'll be fixed or worked around or blocked, no matter what new scenario you come up with. (In reply to comment #63) > I don't understand. The OS has (correction: "had") a security vulnerability, Has, not had. Updates are not magic. Some people have them now; some don't. If it's not 100% then it's vulnerable and hence the block. If a version that is 100% (preferably with user permission) were put out then that could be allowed, as already stated. Fundamentally, Microsoft introduced a security risk into Firefox with these add-ons. That risk came to fruition and thus Mozilla closed the risk entirely. Both have agreed to this, at least for the time being. If you are one of the very small minority that need this software that was by and large installed into users' browsers without their permission or knowledge then I suggest you request Microsoft to write a clean version completely free of this and Mozilla can allow that through. In the meantime, all you need to know on the subject is quite clearly stated in comment 56. Please avoid posting further here if you have nothing new to add. This isn't a forum.
This was obviously pushed through just to make some anti-microsoftie's pud hard. This vulnerability is completely fixed, as much as anyone can know for now in the latest updates. see http://blogs.technet.com/srd/archive/2009/10/12/ms09-054.aspx Yes, there may still be a "potential vulnerability" but that is true for every single plugin/addin and firefox itself. Thanks for disabling something that we were already protected from that we use in line of business applications. I guess our decision to move to firefox company wide was a mistake and we'll have to push out a script to set everyone back to IE as the default browser before Monday if this isn't recalled ASAP.
so now that FF has disabled this plugin, how do i uninstall it? the uninstall button is greyed out?
(In reply to comment #66) > so now that FF has disabled this plugin, how do i uninstall it? the uninstall > button is greyed out? Removal instructions for the first part are here: http://support.microsoft.com/kb/963707 The second part can be removed by deleting the folder: C:\WINDOWS\Microsoft.NET\Framework\v3.5\Windows Presentation Foundation (or similar) Would be nice if a SUMO KB article were added for this.
This is breaking a lot of enterprise customers. The way they will be reacting on Monday is either - disabling a useless blocklist that patronizes it's users by disabling perfectly safe components or - uninstalling Firefox altogether, since you can not lose time playing around with browsers in a business. What you should have done, is giving a message: "There is a security vulnerability, please go to this URL to patch it, otherwise disable the addon" and providing a direct link to the update and a button to disable. But if you are unable to correctly check if the component is actually vulnerable, then don't mess with it.
Microsoft has already fixed the problem at the low level. There was no fix needed in the Microsoft plug in. Now there's no way this will ever get fixed in FireFox unless MOZILLA does something. Almost all add-ons (if not all) rely on OS capability (DLLs). Few (if any) of them go so granular as to check individual versions of each and every DLL in the call chain... most developers don't even know (or care) which system DLLs are invoked in a Win32 call. Expecting the add-ons to check for this is a non-starter. If the OS provider has released a patch (and it has) to the low level OS DLLs, it's not the add-on provider's responsibility to bubble up a new version number nor to release a new version that's bit for bit the same, with the exception of an inc'd version number. The vulnerability was in the OS, not the plug in. At the very least, you need to provide us some way to undo this (to re-enable the add-ons).
1) auto update checking is disabled for Firefox 2) auto add-on update checking is disabled for Firefox Why would Firefox ignore these settings when it is clear updates are not wanted to be checked? beyond this glaring inappropriate action which people generally flee from Microsoft's browser, why would Firefox decide to force an add-on to be disabled with no option to deny such a request? To top it off there is the question of "would you like you restart Firefox" which even when you select later causes a crash ending in all tabs/windows lost. The appropriate action is to only do these checks *if* the client allows for them and *only* if the client allows them. If i wanted a Borg browser that crashes everyhting without letting you choose what you want to happen i would use Microsoft's browser. This is the same exact action Microsoft does when they first forced the install of the add-on which was meet with much distaste. Why would any organization never mind the one directly effect by the same type of event follow the same path where it is clear the users of the software detest such actions? If this is not enough there is no abaility to easily undo the disablement of the add-on which is characteristic of everything hated amongst users of software in general no matter what the software is or it's developer. This was the worst action that could have even been taken and will ultimately severely hurt the adoption of Firefox which is much deserved for these actions.
You did not publish a notice. You did not provide an option. You did not make it known to users that a fix was available through MS and provide them an option. What you did was decide for me and all of my users what was right. What you did was remove functioning technology was taken from the browser without my consent. What you did was make it very obvious to those at the upper management and executive level that we do NOT in fact have control of the application and that we can NOT make it do everything we need it to do. What you did is completely can my efforts to get Firefox instated as our primary browser. What you did is disable an add-on that on our systems is not vulnerable. What you did is make it so that the only work around to turning the tech back on is to disable an otherwise well implemented security tool. What you did is take away the decision of what is best for me and display the fact that you have become Apple in deciding for me. In the many situations where vulnerabilities in the OS leave a potential vulnerability in Firefox, the answer would not be a “yes” (per comment #64), at least not for any core technology. That is the problem. THIS decision was made because this tech not as drastic as the examples provided. In those situations the response would be for Firefox to be redeveloped not to rely on the vulnerable tech. There is history to support this. No, in this situation we are talking about anti MS actions, plain and simple. This is quite obviously an attempt to keep MS out of the FF browser. And congratulations, you have put enough spin on it to be able to stand by your decision. In the end however, this is a LOSS for FF. You may have saved a portion of the non-tech enthusiast crowd by making the decision for them, but likely those users are running FF because a tech enthusiast user installed it for them. Many of the enthusiasts will support this decision, and for them nothing will change. Some could go either way or will forget after some time. For the remaining users however, you have just done something that cannot be undone: you have shown them that they are not in control and they will not like that; they will walk away and that will be the end. The net result will be a loss in the end. But it will go further. Many corporations have begun implementing Firefox and telling their users that it is an equally if not more capable but more secure browser. For a subset of those corporations, the action of removing necessary tech without consent or a secure method for re-enabling it will result in the removal of the browser from the system completely. It will be called a failed experiment. The following day, sys-admins around the world will be left explaining to the non-enthusiast employees that the reversal came because certain business apps would not function in FF. Those users will only hear that FF is not as capable. The correct solution would be to display the notice that the extension might be vulnerable and allow the system admin to make the decision whether or not this was right for them. Further, the default should be to disable the tech, but in the end it should still be a choice.
I have now disabled Firefox' blocklist feature. It's not that I don't think it may be useful, I just don't agree with your policy about it. I have installed the latest MS patches, so I am not vulnerable. But you decided to disable this add-on in spite. Anyway, I will now also uninstall the add-on and the plugin, for the performance reasons somebody mentioned somewhere (either above or in another bug). I hope it's true at least. But then again, I don't think I need that stuff, so I can safely delete it. I certainly won't do that when you decide to block the Flash plug-in because it's again vulnerable to something. This isn't a forum posting, it's a comment on your bug.
Oops, I cannot uninstall the .NET framework add-on because I cannot see it in the add-ons list. Did you uninstall it for me already? Or is the add-ons list broken so that it hides some add-ons from me?
Thank you for the swift action in blocking this and quickly protecting users from a known threat. I think this was the correct action given the circumstances, esp. in the light of the reasons in comment 56.
You're disabling functionality of my web browser without my consent. This is unacceptable - my machine is secure and so by doing this, you're not "saving me" from anything. I will be uninstalling Firefox from all machines under my control after I post this message.
(In reply to comment #75) > You're disabling functionality of my web browser without my consent. This is > unacceptable - my machine is secure and so by doing this, you're not "saving > me" from anything. > > I will be uninstalling Firefox from all machines under my control after I post > this message. Your not making any sense. MS installed the .net and WPF without any warning to you back in Feb. Now, you want to ditch Firefox because they are trying to protect you from something MS should have addressed differently. You would likely be yelling just as loud had you been compromised due to the MS plugin, then blamed Mozilla for the getting compromised. Grow up... this will resolve itself soon I'm pretty sure.
You should've made this at least optional, or made more through tests to verify if security updates are already present. I *do* make use this functionality, and I do not want it to be disabled.
Must agree with multiple other users here. Adding these extensions to the blocklist was unwarranted at this time. The OS level patches for these issues has already been issued by MS on patch Tuesday. What has just been "fixed" was already fixed. This needs to be undone ASAP. In the meantime, I have disabled the blocklist on my browser entirely and now, thanks to this boneheaded move by Mozilla, I get to go into the office on a Sunday and spend an off day disabling this "feature" on dozens of machines. Anyone else needing to disable blocklists, see http://kb.mozillazine.org/Extensions.blocklist.enabled Essentially, open up about:config, search for extensions.blocklist.enabled and toggle the value to false. Dumb move, Mozilla. Dumb. Someone has fundamentally misunderstood the issue and reacted in a kneejerk fashion. When this "fix" gets fixed, I will *consider* re-enabling blocklists. Until then, I'll be spreading the word for people to turn it off.
I don't believe I misunderstood the issue, but in case I did I talked directly with the director at Microsoft responsible for the add-on and plugin -- I would not have requested the blocklist entry addition if they had not agreed. We do want users who _want_ ClickOnce functionality to be able to have it, though that capability needs to be provided by Microsoft. Because the Framework Assistant was deployed through a security update (including to XP, which *only* gets security updates), many users have it who do not want it or even know that it is present, and that they are therefore vulnerable until they install this "IE" patch. It's because of that, and the significant difficulty in uninstalling it properly and fully (including the plugin that it pulls in, and the hidden add-on that can interfere with other add-ons), that we proposed to Microsoft that we block the add-on for now, and they agreed. It's entirely possible that we will want to lift the block in a short timeframe, when we can better see how patch adoption is going. In the interim, we and Microsoft agreed that this was the appropriate path forward; blocklisting without the vendor's consent is not our policy, and not a good idea. We just happen to have the fast-acting tool in this case, so it's through our mechanism that it's disabled.
Excuse me if someone didn't already mention this prior *i got lost and tired of reading the entire thread -to which i will just blame on adhd, a lot of pain and extremely powerful painkillers ;) * .. but from what i did read 30+ years of Dev and comp sec and learning sometimes too much is a bad thing in security and to never back yourself into a dead end with it .. So.. Seems like some what a easy solution would be is to check on patched or unpatched system components using something that should easily be able to incorperate into things, gives a quick method of block listing and no longer block listing certain aspects of Vuln dependancys or plugin's/addon's that become a major security issue. If go by the md5 checksums/or whatever type of checksum/signature wish to use, even if MS does not announce versions,or sneaks in patchs, if the portions which are the root of the Vuln are patched on a system, a checksum of that component would change enabling a possible activation of add-on again. With knowing when such items are patched and working a block list push of a update with sums of known Vuln parts can be pushed out, or opposite, -either whitelist, blacklist, or both , along with version/rev checks or whatnot enabling whenever a patch has appeared and replaced the Vuln dependency with non-vuln one. A option at startup tossed in to allow for checking of add-ons that where disabled due to 3rd party Vulns can be tossed in to enable/disable; So as to now slow down initial start up of Firefox of those who don't care, and for those who do, gives a way of knowing that there add-on is capable of working again and can be enabled once again for there relief of those who had come to rely upon it on large scale corp environments.. Using this as an example, those who have not gotten patched systems, they have the added protection of having there system protected until they do. That way, when components and addon's which rely upon Vuln portions of MS, a simple update through block list updating the blocked item including Vuln sums so it knows weather to kick into action or leave things be can occur. I could think of a few other similar ways given the mechanism that is in place, and given that such features where added, it has lots of potential for keeping browser from being like other ones, which we all know is such a nice doorway for others to share your systems .. ;) excuse any spelling/grammar/etc -can blame on things stated at top of this post- that's my 2 cents for now. *hope that helps in some way*
Mike, you most certainly *did* misunderstsnd(In reply to comment #79) > I don't believe I misunderstood the issue, but in case I did I talked directly > with the director at Microsoft responsible for the add-on and plugin -- I would > not have requested the blocklist entry addition if they had not agreed. > > We do want users who _want_ ClickOnce functionality to be able to have it, > though that capability needs to be provided by Microsoft. Because the > Framework Assistant was deployed through a security update (including to XP, > which *only* gets security updates), many users have it who do not want it or > even know that it is present, and that they are therefore vulnerable until they > install this "IE" patch. Patch Tuesday was on the 13th. They got it then if they have automatic updates. What next, you block Flash every time there is an issue? That would be always, yes? > It's because of that, and the significant difficulty > in uninstalling it properly and fully (including the plugin that it pulls in, > and the hidden add-on that can interfere with other add-ons), that we proposed > to Microsoft that we block the add-on for now, and they agreed. Your didn't give your users an option to agree or disagree. > It's entirely possible that we will want to lift the block in a short > timeframe, when we can better see how patch adoption is going. In the interim, > we and Microsoft agreed Second time you said that. You didn't give your users an option to agree or disagree. Bad move. > that this was the appropriate path forward; > blocklisting without the vendor's consent is not our policy, and not a good > idea. We just happen to have the fast-acting tool in this case, so it's > through our mechanism that it's disabled. You most certainly *did* misunderstand the issue. http://blogs.technet.com/srd/archive/2009/10/12/ms09-054.aspx <Quote> First we’d like to make it clear that any customers that have applied the update associated with MS09-054 are protected, regardless of the attack vector. And most customers need not take any action as they’ll receive this update automatically through Automatic Updates. </Quote> *** As I said, I've turned blocklists off and am responding to people and recommending across multiple forums that others do the same until such time as you folks take the time to actually read and understand what it is that you are doing. Right now you clearly do not. If these items were going to be blocklisted, it should have happened months ago when they were unpatched, not *after* the issues were fixed and a patch was available. This was just a dumb, dumb, dumb move. You're about to lose a great deal of trust and likely some portion of the installed base (those dependent on the functionality of this fixed/patched plugin and extension) who are going to be entirely displeased on Monday morning when this message shows up on business machines everywhere. You simply do NOT handle an issue like this in the way you just did. And in the meantime, a great many will be disabling blocklists and at least some portion of those users will never turn them back on. What are the implications of that? You were wrong. Period. End of story.
I think this is pure paranoia and 1985-ism. What right do you have to decide whether I should be able to use the plug-in or not? Blocking sites whenever you felt like it, for no apparent reason, was bad enough, but at least there was an easy way to disable that feature, and now this? Right now my messenger status is: https://bugzilla.mozilla.org/show_bug.cgi?id=522777#c71 I fully agree with comment 71. While you're at it, why don't you get one step further, and ban access to all sites using IIS, because it's a vulnerable piece of software published by Microsoft, and it could affect YOUR users. How the hell can you say that blacklisting an add-on because it may expose an vulnerability in another component, that was patched days ago is a good idea? And it's not an "IE" patch. It's a Windows patch. If you don't trust Windows Updates, then why do you provide a Windows version of your software anyway? All I ask is: do no evil. But since you seem to be kids playing in the sand, I think Microsoft should patch Firefox and remove the blocklist feature in the next Windows Update, since it disables useful functionality of the OS, affecting THEIR users and THEIR customers. I'm not sure if I should change my messenger status to del /f /s /q "\Program Files\Mozilla Firefox"
(In reply to comment #81) > What next, you block Flash every time there is an issue? That would be always, > yes? If Adobe agreed that it was the right course, we might. Some of us would actually like to blocklist older versions of Flash -- which are versioned properly, and can be distinguished on that basis -- but we likely wouldn't do it without Adobe's OK. > Your didn't give your users an option to agree or disagree. That's true -- our blocklist lacks that capability right now, which is pretty unfortunate in this case; we should fix it, and I think we will, maybe even in 3.6. If we'd had it, we would have used it. This is a very unusual case: the add-on was distributed with an OS security update, can't be properly uninstalled without significant gymnastics (it took me several tries, including manual file deletion of the plugin), has no version information, lies about compatibility with Firefox versions, and has no update channel. And it's on at least half of our users' computers. And it's going away in the next version of the operating system from that vendor, including on the upgrade case. My (incomplete, to be sure) understanding of Microsoft's ActiveX blocklist is that it works the same way -- it's UID based, not version-based, so they expect that a new version of a bogus thing will be made available for people to use. > http://blogs.technet.com/srd/archive/2009/10/12/ms09-054.aspx > > <Quote> > First we’d like to make it clear that any customers that have applied the > update associated with MS09-054 are protected, regardless of the attack vector. > And most customers need not take any action as they’ll receive this update > automatically through Automatic Updates. > </Quote> That text was added to the post after the blocklist was updated (I know because I reviewed that text before it was added to their post), but it was known to me at the time as well. That is labelled everywhere as an _IE_ update, and I don't think we should expect it to be adopted as aggressively by Firefox users as an OS update would be. As I said, I've asked for more information about the uptake rate, so that we can do horrible calculus on user risk versus user inconvenience. I don't *want* to break this functionality. I don't like the add-on, and I don't like the things that it did to the user, but it was the security exposure here -- which we only found out about after it had been made public via the blog post -- that led me to approach Microsoft about blocking the add-on. > You were wrong. Period. End of story. We might be; I might be. There is no *right* here, there is no clearly good outcome -- the people who want ClickOnce can't opt into it because Microsoft hasn't made an add-on available except through this broken, blanket channel. (I don't know what those users will do with Windows 7, or what they did before the SP1 security update pushed the add-on out to the world, tbh.) And those people who want ClickOnce are more likely to be in the care of administrators who *will* make sure they get the updates, and read the SRD blog posts (there's no mention of Firefox or the add-on in the text for the update, that I've seen), so we have a pretty horrible confluence of facts. I envy you the absolute confidence that you seem to have in your position; unfortunately, Mozilla has to make these calls on the basis of an extremely large number of users, with widely different levels of patch hygiene, and an extremely unusual add-on situation. (In reply to comment #82) > And it's not an "IE" patch. It's a Windows patch. If you don't trust Windows > Updates, then why do you provide a Windows version of your software anyway? It's labelled pretty clearly as being an IE patch, which affects Internet Explorer. Please see http://www.microsoft.com/technet/security/bulletin/ms09-054.mspx -- I'm not making this stuff up, I swear! > But since you seem to be kids playing in the sand, I think Microsoft should > patch Firefox and remove the blocklist feature in the next Windows Update, > since it disables useful functionality of the OS, affecting THEIR users and > THEIR customers. I don't know what you're talking about here: this isn't something that we did behind Microsoft's back. We -- I, personally and on the telephone -- spoke to them and they agreed that this was the right thing to do given the facts of the situation. We disabled this add-on WITH THEIR AGREEMENT. We didn't like how the SP1 update jammed things into our users' browser, which is why we talked to them BEFORE we put the blocklist entry up. I don't know how to make this any clearer. Yes, it would have been good to block it months ago after the vulnerability was published and before a fix was shipped. Unfortunately, we didn't know that the exploit in question was reachable through this add-on until after Microsoft publicly disclosed that fact on their blog. If I could go back in time, I would do two things related to this: - add some more richness to our blocklist infrastructure so that we could check OS patch versions, offer more information to users, and so forth; and - block the crap out of the add-on as soon as Dowd and co went on stage at Black Hat. If I got to do a third thing, it would perhaps be: - talk to the Framework Assistant add-on team at Microsoft before they stuck it on untold hundreds of millions of users' machines, so that they could have built it in a way that would have avoided all of this mess.
(In reply to comment #76) > Your not making any sense. MS installed the .net and WPF without any warning > to you back in Feb. Really. When and how did they do this? You're saying that this appeared on my computer without my consent? I don't think so.. I'm *PRETTY SURE* there was an update on Windows Update, and I APPROVED it. > Now, you want to ditch Firefox because they are trying to > protect you from something MS should have addressed differently. How are they protecting me? I have already applied the OS update which resolves the vulnerability. * Posted using IE8.
(In reply to comment #84) > (In reply to comment #76) > > Your not making any sense. MS installed the .net and WPF without any warning > > to you back in Feb. > > Really. When and how did they do this? You're saying that this appeared on my > computer without my consent? I don't think so.. I'm *PRETTY SURE* there was > an update on Windows Update, and I APPROVED it. When I installed the Windows security update in question, I didn't see any mention of it adding an add-on to Firefox. How did Microsoft warn you? I might not have clicked through the right set of links from Windows Update, so I'd be interested to know what the text was if you can be bothered to find it. Thanks!
For information: related bug is bug 476430 - "Warn user that a third party add-on has been installed and allow disabling".
A small update, for those who are following this gripping drama, and can read past the hyperbole: I'm continuing to talk to Microsoft about our joint options here, and I think we'll have a few ways to reduce the impact on people who are patched up and want to re-enable Click-Once. Hopefully before the work week begins, even; neither of us want this situation to be any more invasive than it necessary to protect people, so we'll be working through the weekend on it.
Mike & the rest of the Mozilla team - thanks for being concerned about users welfare, but I have to agree with Nathan (comment #71) & others. I've disabled block list functionality until such time as the improvements Mike mentioned in comment #83 are implemented. I & my users are fully patched, and I prefer making my own informed decisions on disabling add-ons. Please consider publishing the issue and removal instructions, and then withdrawing this item from the blocklist within a few days.
@Dewayne - just so you're aware we put things on the blocklist on a regular basis including a lot of malware. You should check to make sure that you're not opening yourself back up to any other issues, or those of your users by removing the blocklist functionality. We're aware that there isn't a solution here that's going to make everyone happy, but you should realize what happens when you turn off the blocklist.
Mike, Christopher, et al.: From what I've seen of the blocklist feature, you can block by version. So, why did you not just block all versions older or equal to the current ones? If you're really interested in restoring functionality, you could have just done something like that, the same way extensions are checked for compatibility with whatever version of Firefox a user is running. Sorry, but this sounds more like a way to screw over MS and the folks who need ClickOnce, etc., and still come out smelling like roses.
Why are both the ClickOnce extension and the WPF plug-in being blocked? The ClickOnce extension and the WPF plug-in are two separate things. The security vulnerability was in the WPF plug-in which is used to run XBAP app inside the browser (again, see http://blogs.technet.com/srd/archive/2009/10/12/ms09-054.aspx). I am guessing that most of the LOB app users affected needed the ClickOnce functionality for application deployment, not XBAP apps. But regardless of my wild guesses, why are both being blocked?
> From what I've seen of the blocklist feature, you can block by version. When that version is distinguishable through the plugin interface. The plugin itself was not updated by MS there's nothing the current blocklist feature can use to determine whether it's a patched system or not. See bug 522851
So block the current and past versions and leave that window open for Microsoft to push an out of band update with a newer version number. Don't do a blanket job.
Microsoft installed the ClickOnce security hole without proper notification and consent from users. I applaud the Mozilla team for taking steps to disable this malware. If anything, this should have been done in March when Microsoft first implemented its unconscionable plugin installation scheme. I understand how some people who use enterprise software tied into Microsoft technology are collateral damage and complaining loudly, but they are a small minority compared to the vast numbers of Firefox users like myself who use precisely to avoid security risks related to Microsoft's questionable security-usability trade-offs going all the way to ActiveX, to the point where security experts now advise PC users to use a Linux boot disk when using online banking. The long-term solution is to implement the proposals in: https://wiki.mozilla.org/Firefox/Projects/System_Extension_Notification http://www.oxymoronical.com/blog/2009/08/Notifying-users-about-third-party-add-ons This is scheduled for FF 3.7. In the meantime, Microsoft can release an extension with a different GUID, and installed through proper Firefox distribution mechanisms, i.e. not through a back-door leveraging Windows Update.
(In reply to comment #83) > > We might be; I might be. There is no *right* here, there is no clearly good > outcome -- the people who want ClickOnce can't opt into it because Microsoft > hasn't made an add-on available except through this broken, blanket channel. > (I don't know what those users will do with Windows 7, or what they did before > the SP1 security update pushed the add-on out to the world, tbh.) On Windows 7, downloading and executing the clickonce file works. I'm pretty sure this didn't work on Vista last I tried.
I'm waiting to see right now myself, it almost /seems/ like it's fixed the blatant C++ runtime crash error that's been plaguing me since... hmm, updated during summer. That would about be the time when I started having Firefox crashes regularly. And it's using way less processor, at very least. If this stops the C++ errors, then I'd like to thank everyone involved, I was losing Firefox every half hour for a while. I thought it was from having too many tabs open >.< Thank all the universe for session manager, so I didn't lose all my tabs whenever it fell... :)
(In reply to comment #93) > So block the current and past versions and leave that window open for Microsoft > to push an out of band update with a newer version number. Don't do a blanket > job. I believe only one version has been blocked. Unfortunately the Microsoft wrote their security fix such that both the fixed and unfixed version use the same version number. Thus we can't tell them apart. If microsoft released an update that changed their version number they would not be blocked.
Flags: blocking-firefox3.6?
(In reply to comment #97) > (In reply to comment #93) > > So block the current and past versions and leave that window open for Microsoft > > to push an out of band update with a newer version number. Don't do a blanket > > job. > > I believe only one version has been blocked. Unfortunately the Microsoft wrote > their security fix such that both the fixed and unfixed version use the same > version number. Thus we can't tell them apart. > > If microsoft released an update that changed their version number they would > not be blocked. What you and everyone else seems to be missing is that there's no updated version because there is not an updated version of the add-ons! The WPF extension was not vulnerable in and of itself. The WPF host process that it communicates with had the vulnerability. The Microsoft update fixed the problem with the host process, thus closing the vulnerability that was exposed through the extension. There was no update at all to the extension because one wasn't needed. Personally, I'd like to know who the person is at Microsoft that is supposedly on board with this block.
(In reply to comment #98) > Personally, I'd like to know who the person is at Microsoft that is supposedly > on board with this block. Perhaps, but it's not my place to reveal their identity. If you want to call me a liar you should just do it, rather than weaselling around with "supposedly". It's fewer words, if nothing else.
Now that you have prevented me from viewing video on CNN News, what do I do to get the ability back ?
To everyone who wants to complain about the enterprise issues: I have been and will continue to be a firefox user for a long time and this issue isn't going to change that - The click once functionality was not something I or many other users of firefox asked to be installed and in fact would not have wanted installed without my request to do so - Thus if a release of the WPF or dotnet assistant were to be released that could be pushed out to a windows domain (login script) or installed as needed by the user base that wants the application then I'm all for not blocking those instances, however installing any application without my consent (meaning I'm clearly aware of the implications of installing said software - being that IE vulnerabilities become mine, and assuming that future IE vulnerabilities would be also affected by this plugin) is just plain unacceptable and I am 100% for the block and would have as well voted for the block. and to close: Why would those that have stated such a complete dependency on this one-click system be so blind to the implications on the majority of the users that just don't want MS installing software without approval and would in a moments notice block something that opened them up to continued vulnerabilities? Why also would you allow yourselves to be so dependent on a Firefox based installed when you have domain push controls for your entire organization - browser based tools require your end users to open that page and install the patch - whereas your domain push tools (which work both in network and out of network over VPN) do not require your users to do anything but login to the machine (and can even be pushed out without log ons)? Please consider the reality of your trust security environments if you are dependent on a user clicking an item in firefox - then you are creating a major potential for other security risks, and to boot - opening a much greater hole to future bad practice in your methods. I do support the decision made by the Microsoft and Mozilla teams with regards to this bug.
CNN Video works for me, with this disabled. I think you're experiencing a different issue, please do file another bug for it.
I don't know how many times this needs to be said, but The WPF plugin and ClickOnce extension, while both installed by .net3.5 sp1, are not the same thing. The WPF plugin allows Firefox to host XBAPs. The same way that Flash player allows Firefox to host SWFs. The ClickOnce extension alters the user agent and adds a "Run with ClickOnce" button when you try and open a clickonce application link in Firefox. ClickOnce is a deployment (application installation) technology with only tenuous links to the .Net Framework. Google Chrome for example uses it to install. You can think of it like having Adobe Reader installed, but with "view in browser" off, and for applications. Sort of. The bug that Microsoft fixed was in the system that makes sure that untrusted code was safe. XBAPs include untrusted code (because they are hosted without prompting, just like flash), and as such are a vector to reach this particular bug. The point is that they are completely different.
>What you and everyone else seems to be missing is that there's no updated >version because there is not an updated version of the add-ons! The WPF >extension was not vulnerable in and of itself. The WPF host process that it >communicates with had the vulnerability. The Microsoft update fixed the >problem with the host process, thus closing the vulnerability that was exposed >through the extension. > >There was no update at all to the extension because one wasn't needed. What you and a few otherare missing is that the addon/plugin and the whole .net Framework package (which is not a core OS functionality) is one single unit, in the Java world it's called JRE=Java runtime environment which contains a plugin/addon like and a JVM (Java virtual machine). If sun releases a new version of the JRE because they fixed an security issue in the JVM they will release a new JRE version that contains a plugin with a raised Version number. MS just failed to patch their software correctly. Either ask Microsoft to do it right with their security fixes or live with the consequences that Mozilla.org blocks already patched systems because there is no other way for Mozilla.org to do what nearly all users expect from Mozilla.org. removing blocking request because this is an already fixed bug and the fix works as expected
Flags: blocking-firefox3.6?
It is up to me how I use your browser. If I want WPF that's my decision and is certainly not yours. I could understand a one-time warning along the lines of "You have this plugin installed and enabled. It has been known to cause issues for some users <link here>, do you want to disable it?"
I can't believe a bunch of Microsofties want something installed which is a blatant security risk. Add one vote for people who didn't ask to keep something installed that we never asked to be installed in the first place. Good riddance and proper ban.
(In reply to comment #105) > I could understand a one-time warning along the lines of "You have this plugin > installed and enabled. It has been known to cause issues for some users <link > here>, do you want to disable it?" We want that too. We're working on it. We were dealing with a public vuln (we didn't find out about it until it was blogged), so we went with what we had, and we have people working the weekend (of their own accord, I should add; nobody wants to make our users angry) to get to a better middle ground for this pretty unusual situation.
If I may chime in as a bystander to this fight: As understand the issue, Mozilla could have used its blocklist mechanism right if Microsoft had been smart enough to update the version number or name of the installed plugins along with their security patch. A solution would be to do this now and thus make the functionality work again for those who want it. If you want to assign blame, which doesn't help anyone, Microsoft first messed things up, but now when trying to fix it both Mozilla and Microsoft have made suboptimal decisions, IMO.
Blocks: 522952
(In reply to comment #96) > I'm waiting to see right now myself, it almost /seems/ like it's fixed the > blatant C++ runtime crash error that's been plaguing me since... hmm, updated > during summer. That would about be the time when I started having Firefox > crashes regularly. And it's using way less processor, at very least. If this > stops the C++ errors, then I'd like to thank everyone involved, I was losing > Firefox every half hour for a while. I thought it was from having too many tabs > open >.< > > Thank all the universe for session manager, so I didn't lose all my tabs > whenever it fell... :) Thank you very much for stepping into the fray to report this. Reports of crashing were noted up in comment 1 and the performance problem was reported in a support request noted in comment 4. It's nice to get some confirmation that this is also stopping some of these problems for at least some people, even though that wasn't the primary reasoning for the block itself. If it does recur for you at some point with these add-ons disabled then I suggest you file a new bug for your problem so it can be looked into.
(In reply to comment #109) > > Thank you very much for stepping into the fray to report this. Reports of > crashing were noted up in comment 1 and the performance problem was reported in > a support request noted in comment 4. It's nice to get some confirmation that > this is also stopping some of these problems for at least some people, even > though that wasn't the primary reasoning for the block itself. If it does recur > for you at some point with these add-ons disabled then I suggest you file a new > bug for your problem so it can be looked into. It seems unfortunately that it might not be the case, this morning the C++ crash happened again. *sigh* It does seem to run quicker, and eat less processor though. I'd hoped from the sounds of the comments that this might be the one. Ehwell. It's quicker about getting back together than it was, now.
(In reply to comment #110) > It seems unfortunately that it might not be the case, this morning the C++ > crash happened again. *sigh* It does seem to run quicker, and eat less > processor though. I'd hoped from the sounds of the comments that this might be > the one. Ehwell. It's quicker about getting back together than it was, now. Well, some improvement is better than none. :) Please file a new bug for the crashes. A good starting point for troubleshooting this is here: http://support.mozilla.com/en-US/kb/Basic+Troubleshooting http://support.mozilla.com/en-US/kb/Firefox+Crashes
(In reply to comment #107) > we have people working the weekend (of their own accord, I should add; > nobody wants to make our users angry) to get to a better middle ground for this > pretty unusual situation. Thanks for recognizing the urgency and importance of the Click-Once technology of your users and putting in the extra effort to help the millions of people that really really really need this!!! Just make sure that the average, non-techy Joe user who will be running our business critical apps Monday morning will be able to do so without overwhelming our help desks. A link to a page explaining what Joe User needs to do (if anything) would be greatly appreciated, so that we may direct our users to it and so that we may provide a link to it on our web pages that host the link to our apps. Also, please understand that part of Click-Once deployment is that some apps put an icon on the desktop that reference the .application URL, so there will be no web page for those applications. They go straight to the .application URL. Thanks again for putting in weekend time to resolve this!!!
I was reading the notice on Microsoft's site: http://blogs.technet.com/srd/archive/2009/10/12/ms09-054.aspx and, unless I missed something (which is entirely possible), it looks like the add-on affected was the WPF add-on and not the "Microsoft .NET frameowrk Assistant" add on which provides the Click-Once capability. The vulnerability seems to be in WPF displaying XBAP apps, which, from my understanding, the Click-Once add on is not involved. If this is the case, perhaps the .NET framework add on that provides the Click-Once capability could be re-enabled pronto, but deal with the WPF issue as you're doing over the weekend?
Is there a way to disable this blocking service? What on earth kind of **** is it when a few zealots can decide to disable or block services like this. It'd be one thing if it happened because of enterprise policy or because of some spyware product I'd installed, but to be told this morning that you'd decided that a previously safe and useful product was now unsafe for my consumption and to make it impossible to get it back--especially without any proof or real vetting process--is ludicrous. This is every persons FUD about open source come true and you wonder why IE still rules the corporate world.
notwithstanding the right-to-block-or-not issue, as a mid-level techie who just got the message for the first time, my reaction is: what the heck is anything from MS doing in my FF browser?!?!?! Get it out quick and thanks for bringing it to my attention! I installed an HP printer a while back and was shocked to see that their software installed a FF add-on on my behalf. I didn't ask for that and resent it being added without my knowledge. I don't blame FF. I blame HP. Unless maybe FF should not permit the unauthorized add-on. that's another story... sorry.
Whiteboard: [see comment 56] → [see comment 56 & 83]
I really don't think that anyone defending Mozilla's decision to block the .NET Framework Assistant has any clue about the ramifications come Monday morning. Publishing .NET windows applications to a web server and then making these applications available through a web browser has become an extremely efficient and SAFE (inside the Firewall) deployment method. Yes, there truly are many of us IT Administrators out there who have purposely installed the .NET Framework Assistant so that our FireFox users would not have to switch over to IE in order to run these applications. Mozilla's knee jerk decision has literally pulled the rug out from under any attempt to promote FireFox as the browser of choice in my organization as well as THOUSANDS more who will be completely blind-sided come Monday morning.
Question for you: when you say that you purposely installed, do you mean that you directly installed the add-on? As I understand it, all the Framework Assistant does is integrate the ClickOnce option into the handling for a certain MIME type, where save-and-run would always have worked. (I'm on Windows 7 here, so I can't test it right now, sorry.) But if you're directly installing the add-on to machines, contact me via email (shaver@mozilla.com) and we can try something that may work for you, before we hopefully roll out a better fix tonight. Thanks for taking the time to comment!
The save-and-run does not work because the file that launches is a manifest, sort of like an ini file which points to the appropriate application files that reside on the server. The ironic thing is that even when ClickOnce is enabled, the user is always given the choice to RUN/DON'T RUN everytime the manifest is accessed from a different browser as well as everytime the manifest is updated in any way.
By the way, the described functionality works the same way, whether you are running XP, Vista, or Windows 7.
Are you using the RTM of Windows 7? The WPF plugin and .NET Framework Assistant were removed from Windows 7 between RC and RTM (confirmed through test and by Microsoft), so that would be surprising to me and some people who work on those pieces of software, I think. Hmm.
> What you and a few otherare missing is that the addon/plugin and the whole .net > Framework package (which is not a core OS functionality) is one single unit, in > the Java world it's called JRE=Java runtime environment which contains a > plugin/addon like and a JVM (Java virtual machine). Single unit? That must explain why they were able to update one and not the other… Just because it was initially deployed together doesn’t mean it is a single unit. For each person who has complained that MS installed something without their consent: I would argue that Mozilla has just UN-installed something without consent. Neither is any better than the other. I will not defend Microsoft’s decision to install the add-on, but I was aware of its presence and choose to leave it installed. Mozilla has gone a step further with this however. MS installed software; that software may have been launched only through FF but it was separate in that it did not modify FF or any other plug-in installed. Mozilla on the other hand has made a change that affected the functionality of Microsoft’s software for a third party. For each person who has defended Mozilla’s decision on the basis of this is to protect unknowing users: Thank you for making a decision for the whole based on only a part of it. What makes them more important than the rest again? I seem to have forgotten. This decision reeks of Apple-juice. *Posted using IE8
(In reply to comment #120) > Are you using the RTM of Windows 7? The WPF plugin and .NET Framework > Assistant were removed from Windows 7 between RC and RTM (confirmed through > test and by Microsoft), so that would be surprising to me and some people who > work on those pieces of software, I think. Hmm. Not sure who you were asking, but here's what I've found with Windows 7: I'm running Windows 7 Ultimate 64 RTM at home and the .NET Framework add-on is installed and was indeed working until the block. I don't see the WPF add-on listed in my add-ons. But, this W7 in an upgrade from Vista. I'm going to remote in to my W7 Ultimate 32bit at the office and let you know what I find there. That instance is a fresh install, not an upgrade. FF was not installed, so I'll have to install it. Not sure if that invalidates the test since it's been said that the a patch for .NET 3.5 installs this (or perhaps the installation of 3.5 itself?)
Will the ClickOnce extension still be blocked tomorrow morning (as opposed to the WPF/XBAP plug-in)? Only the WPF plug-in had the vulnerability and it is clear from comments #8 and #9 that you can block while and not the other. I can understand why both were blocked while things were sorted out, but it should be clear now that the problem was only in the plug-in and not the extension.
It would be unfortunate if the ClickOnce functionality that works so well in the RC is no longer available in the RTM... I guess that would mean any resolution developed over this weekend would only buy us a little time before we would be forced to switch over to IE anyway. All for what? Because Mozilla is unwilling to work with Microsoft to make FireFox even better?
I am waiting for final confirmation that the add-on is not a vector for the exploit in question; I can't see all the relevant code, so I'm waiting for people who can to give me the all-clear. Nothing would please me more than to remove it from the blocklist if we know it's safe. We are in the process of pushing an update to our blocklisting software that will allow users RUNNING FIREFOX 3.5 to override the blocklist for this entry, since there is no way for us to determine through plugin/add-on version whether the system is patched or not. I'll update here when it's live. I believe that there will be a solution for Windows 7 users; we have offered our help to Microsoft on that topic, and it is a genuine offer. I don't think they want to inconvenience users any more than we do, but it's not appropriate for me to speak to their plans. Sorry I can't say more.
Just a bit of history on this add-on... Even though the current incarnation of this add-on may very well be installed automatically without asking, the first year or so, you had to hunt it down on the internet and find it and install it, which is how I got it installed... I actively sought it and installed it manually before MS decided to make it automatic. This isn't to prove a point. I just thought it was important to note this because so many people are upset about the current incarnation of it being automatic, justified or not.
I think this Click-Once technology is important enough that the Mozilla folks should probably get up to speed on it. From the comments left here, I can see that this is an unfamiliar technology to them. I wrote up a quick and dirty explanation here: http://csharpner.blogspot.com/2009/10/what-is-click-once-technology.html with a link at the end of that article to Microsoft's more in-depth information. The quick overview I provided was directed specifically at the Mozilla guys working this issue right now. I think knowing that little bit of it will make things a little more clear for their work for the weekend, while the MS link I added at the end can give more details, should they need it. Hope this helps.
Mike, we do appreciate your due diligence. I suppose I am simply somewhat disappointed that some resolution hasn't already surfaced over these past months since the .NET 3.5 SP1 fiasco. Thanks for your continued help and your understanding regarding this important issue.
Both installed on Win7 Ultimate/32 RTM: WPF 3.5.30729.4918 MS .net FA 1.1 In response to comment #125. This would make me happy. Too bad it wasn't in place when this block was pushed. Any sort of ETA?
(In reply to comment #122) > (In reply to comment #120) > > Are you using the RTM of Windows 7? The WPF plugin and .NET Framework > > Assistant were removed from Windows 7 between RC and RTM (confirmed through > > test and by Microsoft), so that would be surprising to me and some people who > > work on those pieces of software, I think. Hmm. > > Not sure who you were asking, but here's what I've found with Windows 7: > > I'm running Windows 7 Ultimate 64 RTM at home and the .NET Framework add-on is > installed and was indeed working until the block. I don't see the WPF add-on > listed in my add-ons. But, this W7 in an upgrade from Vista. > > I'm going to remote in to my W7 Ultimate 32bit at the office and let you know > what I find there. That instance is a fresh install, not an upgrade. FF was > not installed, so I'll have to install it. Not sure if that invalidates the > test since it's been said that the a patch for .NET 3.5 installs this (or > perhaps the installation of 3.5 itself?) Just installed FF on my W7 Ultimate 32bit VM at work. Before I installed it, there were updates waiting to be installed (I believe the MS fix was one of them). I let those MS updates install, then rebooted, then installed FF. Neither of those add-ons are installed and Click-Once does not work from FF. I'm not sure what MS's plans are for FF & W7.
jwood: re comment #124, if MS did remove the ClickOnce extension from Win7, it's probably because they'd rather be bitched out for having something that works in their browser and not in others, rather than bitched out for "sabotaging" other people's software. The open source community loves to put Microsoft in a "damned if you do, damned if you don't" position, so they're probably just going for whatever causes them less stress and hassle. After all, with the ClickOnce extension listed on AMO (until it was taken down along with the blocklist) Microsoft could simply point people there if they wanted it, and not have to spend the time and money on PR to deal with complaints.
(In reply to comment #89) > @Dewayne - just so you're aware we put things on the blocklist on a regular > basis including a lot of malware. Oh, really? Let's see all the items on the current blocklist (from https://www.mozilla.com/en-US/blocklist/): <cite> Internet Download Manager, v2.1-3.3 for Firefox 3.0a1 and newer. Reason: caused startup crashes (see bug 382356). Free Download Manager, v1.0-1.3.1 for Firefox 3.0a1 and newer. Reason: high crash volume (see bug 408445). Yahoo Application State Plugin, v1.0.0.5 and older for Firefox 3.0a1 and newer. Reason: high crash volume (see bug 419127). Vietnamese Language Pack, v2.0 for all applications. Reason: corrupted files (see bug 432406). Apple QuickTime Plugin, v7.1.*, for all Firefox 3 versions on Windows. Reason: remote code execution in multiple versions (see bug 430826). Crawler Toolbar, for Firefox 3.0a1 and newer. Reason: high crash volume (see bug 441649). Daemon Tools Toolbar, versions older than 1.0.0.5, for all applications. Reason: high crash volume (see bug 459850). AVG SafeSearch, versions older than 8.0, for Firefox 3.1a1 and newer. Reason: breaks a core navigation method (see bug 479095). Microsoft .NET Framework Assistant and Windows Presentation Foundation, all versions, for all applications. Reason: remote code execution vulnerability (see bug 522777). </cite> Seems to me that this list includes not malware, but only some "problematic" plugins/addons. Moreover, Mike in comment 79 mentioned that "blocklisting without the vendor's consent is not our policy, and not a good idea" -- and you obviously don't get consent to block some malware from its vendor ;-). > You should check to make sure that you're > not opening yourself back up to any other issues, or those of your users by > removing the blocklist functionality. > > We're aware that there isn't a solution here that's going to make everyone > happy, but you should realize what happens when you turn off the blocklist. Really, what horrible is going to happen when someone turns off the blocklist? Please, elaborate. I suspect that Mozilla is unhappy with disabling the blocklist also because it allows them to get live stats about users: see eg. bug 430120 or 503341 comment 0. I guess this is also one of the reasons why it is impossible to disable it within UI.
(In reply to comment #132) > allows them to get live stats about users: see eg. bug 430120 or 503341 comment > 0. I omitted "bug" before the second bug number and bugzilla made a bad link. A proper one, hopefully: bug 503341 comment 0. (In reply to comment #114) > Is there a way to disable this blocking service? What on earth kind of **** is As far as I know there is no way to disable it within UI. See comment 78 for instructions using about:config.
(In reply to comment #132) > Seems to me that this list includes not malware, but only some "problematic" > plugins/addons. Moreover, Mike in comment 79 mentioned that "blocklisting > without the vendor's consent is not our policy, and not a good idea" -- and you > obviously don't get consent to block some malware from its vendor ;-). A generalized usage of the word "malware" is just any software that's breaking things, possibly installed without user consent. I'm sure we could debate about whether this accurate enough (it may not be). The point was clearly that the list does block things which are serious problems, i.e. startup crashes, etc. Once the soft block system is fully implemented it may get more use in the future and will probably be less controversial.
>Seems to me that this list includes not malware, but only some "problematic" >plugins/addons. The QT Plugin is blocked for security reasons, that's not problematic, that is a security risk like this one but Apple provied version information in the plugin and good versions are not blocked. There is adware blocked, see bug 512406 >Moreover, Mike in comment 79 mentioned that "blocklisting >without the vendor's consent is not our policy, and not a good idea" -- and you >obviously don't get consent to block some malware from its vendor ;-) I hope you know that this part of your comment is stupid ? >I suspect that Mozilla is unhappy with disabling the blocklist also because it >allows them to get live stats about users The stats doesn't matter because you can also use the Addon update ping for that. The few users who disable that doesn't matter for the stats.
We received confirmation a couple of hours ago from Microsoft that the add-on itself is not a vector for these vulnerabilities, so we've removed it from the blocklist. You may revel in your clickonce-ing again, apologies for the inconvenience and thank you for your patience. We're still working on the overridable block for the WPF plugin, updates on that when I have them!
Summary: Blocklist all versions of "Microsoft .NET Framework Assistant" extension and associated "Windows Presentation Foundation" plugin (installed automatically via .NET Framework 3.5 SP1 update) → Blocklist "Windows Presentation Foundation" plugin (installed automatically via .NET Framework 3.5 SP1 update)
.NET Framework Assistant is back up on AMO @ https://addons.mozilla.org/en-US/firefox/addon/9449
(In reply to comment #136) > We received confirmation a couple of hours ago from Microsoft that the add-on > itself is not a vector for these vulnerabilities, so we've removed it from the > blocklist. You may revel in your clickonce-ing again, apologies for the > inconvenience and thank you for your patience. > > We're still working on the overridable block for the WPF plugin, updates on > that when I have them! Thanks for correcting this! Much appreciated!!! Now, what do we need to do to get this corrected on our and our users machines?
Shouldn't http://www.mozilla.com/en-US/blocklist/ be corrected to reflect this latest change?
(In reply to comment #53) > What's making this worse is that MS installs this addon/plugin not as opt-in or > opt-out component, they install it without asking and you can only choose to > uninstall it later like many malware while an opt-in install would be the only > fair solution. Many users didn't notice this installation and MS got enough bad > press about this and blocking the plugin is the only right solution to protect > such users that didn't notice this in the back installation. > I think this points to a fundamental flaw in the Firefox security model. A plug-in should only be enabled if it is *explicitly* accepted by the user -- i.e. Firefox should be working off a plug-in whitelist, not a blocklist. There have been several instances over the past year or so where plug-ins have mysteriously appeared because some 3rd party software installed it into a Firefox folder. I think it's time to change that Firefox change its own security model to explicit opt-in.
Ditto, Bill - comment #140. Refer to bug 476430, as pointed out by BartZilla on comment 86.
>I think this points to a fundamental flaw in the Firefox security model. Wrong, Firefox can not secure you from software that you (!) allow to run on your system with the privileges to add it to Firefox. It would be very easy for the Plugin installer to add the plugin to a whitelist that Firefox is using.
(comment #142) > It would be very easy for the Plugin installer to add the plugin to a whitelist that Firefox is using. That's a good point. But can't the reverse argument be used, that black lists are manipulable as well?
If you assume that the malware runs the whole time in the background on a system then yes, everything is lost on that system but it helps with the usual adware crap that is installed once and where nothing runs in the background. The blacklist will be updated every 60 minutes AFAIK and overwritten with the new version.
(In reply to comment #142) > >I think this points to a fundamental flaw in the Firefox security model. > Wrong, Firefox can not secure you from software that you (!) allow to run on > your system with the privileges to add it to Firefox. It would be very easy for > the Plugin installer to add the plugin to a whitelist that Firefox is using. The problem is that I don't give them privileges to affect Firefox -- I install the software for other reasons. Bad on them for going behind my back; bad on Firefox for letting them. I think this is a basic security strategy in this day and age -- assume the worst of all software and only allow that software to be enabled when explicitly authorised by the user. Firefox already does this for extensions so why not for plug-ins? Note that the solution may require something a little more sophisticated that a simple whitelist that can be easily overwritten.
>The problem is that I don't give them privileges to affect Firefox You do because the software would not be able to write the files (addon/plugin). >I install the software for other reasons Tell that the software that you run it only for reason x and it would be nice if it follows your wishes. >I think this is a basic security strategy in this day >and age -- assume the worst of all software and only allow that software to be >enabled when explicitly authorised by the user. Firefox already does this for You explicit allowed that if you run the software that installs something under an Account that contains the system rights to write the files. If you let software run under admin privileges under windows it can do everything that it wants because you allowed it. It can format your hdd, it could replace Firefox with Netswcape3.0, it could send every file stored on your hdd over internet after it disabled the Firewall. If you let software run only only with your user Account rights it will be limited but that is still enough to modify files that are in your user profile including your Firefox User profile. >extensions so why not for plug-ins? Note that the solution may require >something a little more sophisticated that a simple whitelist that can be >easily overwritten. There is no protection possible, not for addons and not for plugins if you run the software on your system with the rights to change the files. Only the OS can limit the rights of such software and no usermode application like Firefox can protect it's data-files for modifications. But this discussion doesn't belong into this bug or in bugzilla . This bug is limited to the blocklist of the .Net addon and Plugin.
Why the hell can't I enable the WPF plugin? I need that plugin for XBAP applications. Idiots!!!!
This is a very good discussion. This is a very bad place for it. Please continue it in dev-apps-firefox (mozilla.dev.apps.firefox via google groups or news.mozilla.org, dev-apps-firefox@lists.mozilla.org via email) where it will be seen by the right people, and not interfere with what we're doing with this set of blocklist entries. Thanks to everyone who's commented so far -- even people who are rude are trying to contribute, I'm sure. We're on the cusp of making the WPF block overridable, and I'll update here when that goes live.
That's good.. I was thinking that maybe we should let MS know that they need to possibly squeeze out a new addon with a different version number and GUID, which itself checks to make sure the appropriate MS patch has been installed. If it fails this check, then perhaps the addon can disable itself?
(In reply to comment #132) > Seems to me that this list includes not malware, but only some "problematic" > plugins/addons. The list on the page is not the complete list if you open the actual blocklist file. I'm not sure whether it's our policy to not list the malware on the page, whether we forgot a couple of page updates, or if we just don't know what to call these things. The current blocklist also includes <emItem id="{2224e955-00e9-4613-a844-ce69fccaae91}"/> <pluginItem> <match name="filename" exp="NPFFAddOn.dll"/> <versionRange></versionRange> </pluginItem>
@ Mike Shaver + Daniel Veditz So...does this WPF plugin have, or have not, anything to do with Firefox UI "freezing" issues? For instance: Typing in any text input area in the browser window causes "stuttering" where the entire UI seems to freeze, dropping some input from the keyboard/mouse and then suddenly displaying several typed objects at once. Happening right now while typing in this message, and definitely happens when typing in the URL and Search bars. This never was a problem until .NET 3.5 SP1 (with the WPF updates) and Firefox 3.5 were both installed.
Setting this plugin as disabled is a major shutdown for anyone wanting to run xbap applications. Honestly it seems like a major hammer on things... not a good solution, and I'm very disapointed with this logic of thought... hope this gets reversed soon...
What caused the problem , serious question to ask. 1- it was not the blocking of a vulnerable piece of software ,but the inability of detection of patched software . 2-Also no problem of .net package installing add-ons secretly on Firefox , but the inability to remove them fast and easy . Here are some suggestions to avoid similar problems in future . 1- for first problem , firefox should force plugins to explicitly identify executables the call outside firefox or what may be called host applications. these host applications should be identified by their version number and hash check ( MD5 or SHA1 ) . if identication fail for any reason , e.g. : plugin does not specify info , or hash test of host application fail to equate with identified hash value ; this plugin should be prohibited from running this host application . this will ease the check of blocklisted host application and force security mechanism . software vendors will update their plugin when updating their host application to comply with this mechanism 2- for second , firefox should verify that addon is uninstallable , before allowing it to install . exactly as when installing msi package , it is responsibility of Microsoft installer to correctly install it and uninstall it . this on contrast to installing with exe file , which may provide an uninstall utility or not . i.e , firefoxshould allow only package (xpi ) installs of addons , this package installed could be invoked from an exexcutable , as there is exe that invoke msi install . Best regards for your effort respecting both the security and usability of users. I feel like they are nearly conflicting as security requires minimal approach and usability requires maximal approach .
>1- it was not the blocking of a vulnerable piece of software ,but the inability >of detection of patched software . Wrong, vulnerable Software got blocked. The software is the net framework with it's plugin and that is one single unit like the Sun JRE (JVM+Java plugin). The block affected the fixed/patched .net framnework which is now blocked because MS failed to provide Version numbers. >1- for first problem , firefox should force plugins to explicitly identify.... This is a NPAPI Plugin (NPAPI is used by all browsers except IE5+) and there is nothing in the NPAPI standard that allows to do such things because they are not necessary. NPAPI plugins can and should report a correct version number and every major plugin gets this right except this MS Plugin >2- for second , firefox should verify that addon is uninstallable , before >allowing it to install Firefox didn't allow the installation, the user who started the installer did that and the files got installed outside of Firefox. If you run software on the system that is allowed to modify files than Firefox can not protect you against this because the installer can integrate files into Firefox by directly modifying all Firefox files. Again, a very good move from Mozilla.org and if you are disappointed about this sitúation you should write this to Microsoft (installed addon+Plugin without asking and a broken plugin without correct version strings). I hope that the plugin will be blocked for a longer time. MS should release a fixed plugin with a new version string and the issue is gone. USers who need this plugin can anable it now manually again.
At the end of the day YOU SHOULD HAVE A CHOICE whether to install an add-in/plug-in, therefore if you require the un-secure add in for your business then that's your CHOICE. You shouldn't be force fed vulnerabilities for sure, especially if they haven't (obviously) been road tested properly before they were released.
(In reply to comment #148) > Thanks to everyone who's commented so far -- even people who are rude are > trying to contribute, I'm sure. > > We're on the cusp of making the WPF block overridable, and I'll update here > when that goes live. Mike and I both meant to update this bug yesterday, and both forgot to do so, sorry about that. The blocklisting of the WPF plugin is now overridable. You can open your addons manager, choose the plugin from the list, and click "Enable" to re-enable it. Microsoft is watching patch uptake for this plugin, and once it reaches saturation (likely in the next day or two) we will remove the entry completely. For more information, see Mike's latest blog post, here: http://shaver.off.net/diary/2009/10/19/update-on-the-net-framework-assistant-and-windows-presentation-foundation-plugin-blocking-from-this-weekend/ If you have further comments on blocklisting policy in general, please take those to the mozilla.dev.apps.firefox newsgroup: http://groups.google.com/group/mozilla.dev.apps.firefox/topics?lnk Concerns beyond the specific software impacted in this bug don't really belong here, and each additional comment now sends email to at least 70 people, so please be conservative in your choice to add one.
We've got the saturation information from Microsoft that we were looking for, so we can remove the remaining blocklist entry (and update the web page). Morgamic: take it away!
The WPF blocklist entry has been removed. Show's over!
Resolution: FIXED → WONTFIX
Just committed the change to the website. This should get reflected on the blocklist page in the next 30-45 minutes.
Product: addons.mozilla.org → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: