Blocking Extensions that are installed by surprise

[Frank Lion]

Wouldn't setting xpinstall.enabled in about:config to false accomplish much the same thing ?

No. That would, and does, block remote (websites) installs only, apart from the Mozilla Addons site.

********

I've tested this extension/theme blocking method, that I outlined above, on copies of real profiles that had 20 or so existing extensions and used every trick I knew to corrupt the profile, but it was fine. However, backing up your profile before doing this is a very good idea.

With this method of Read Only status, it should be noted that the 'Not compatible with...' messages that are shown in the Addons Manager are meaningless. Firefox only has a certain number of error messages, finds it cannot write to this file and ... ..thinks..'I'll show the old non-compat message, that'll have to do.' Just select Uninstall to get them to vanish out of the Addons Manager.

Vanilla is right when he states that a determined exe could change the ReadOnly attribute back, but do remember that the profile names are encrypted, so the pathing to these is not over easy.

Finally, I suggest making a note somewhere if you change to 'Read Only' status on the extensions.rdf as these things are pretty easy to forget in the future.

Onwards...

************

Plugins.

A short intro and then into KB mode I think, as this one is a bit more complicated to sort. (20 mins max)

Although the Firefox profile's pluginreg.dat does indeed contain a list of plugins, altering the attributes here will achieve zilch. This is because plugins are applied globally and are not profile specific. Therefore, to suppress the Firefox recognition of rogue plugins, we need to take a global approach to revert the very thing that was intended to make things easier, i.e. plugin auto detection.

so...

1. Check this out - http://kb.mozillazine.org/Plugin_scanning

2. Enter about:config in urlbar and enter the term 'plugin' in the searchbar -






3. Select plugin.expose_full_path, right click and toggle to true.

4. In a new tab, enter about:plugins in the urlbar. Copy the folder path of the Mozilla Default Plug-in (C:\Program Files xxxxxxxxxx\xxx\plugins or whatever) and enter this path into the Address bar of Windows Explorer (i.e. your local file browser), this will take you straight to the correct destination folder for stages 6 onwards.

5. Back to the about:plugins webpage. You now have a choice as to whether to leave the Java (SunJRE), Acrobat, WMP, Quicktime stuff alone or not. If you do want to limit these, then follow the about:config changes for these detailed in the KB link above.

6. In about:plugins, copy the folder paths of the plugins you wish to keep, i.e. C:\WINDOWS\system32\Macromed\Flash\ and paste that path into your local file browser. Copy the required .dll, in this case NPSWF32.dll, and paste this .dll into the Firefox application plugin folder (see Stage 4) Repeat this process for all required plugins.

7. Return to about:config and select plugin.scan.plid.all, right click and toggle to false.

8. Restart Firefox, plugin auto detection is now disabled, your desired plugins are in the correct folder and, er, you're done.

******

Notes:

a. When you update, say Flash, you will have to move the new Flash .dll over, but remember that about:plugins will not be showing you the path to the original location any more...so make a note of it now!

b. I've tested all this using Silverlight (nice small download ) and all works fine. Be aware, however, that in theory (?) rogue plugins could try to install directly into the Firefox application plugin folder. This could be prevented (?) by having the Firefox application in an unexpected location, i.e. not C:\Program Files. This is easy when, as I do, using .zip builds, but may be quite a chore for installers. Suggest we cross this bridge when/if we come to it. Meanwhile, just keep an eye on the Plugins section of the Addons Manager for suspect plugins.

[VanillaMozilla]

Vanilla is right when he states that a determined exe could change the ReadOnly attribute back, but do remember that the profile names are encrypted, so the pathing to these is not over easy.

It is overly easy. If you can read the directory, so can an application. It's not too difficult to guess which profile is the active one--just pick the most recently modified. Or to be sure, it could easily check all profiles for locked files. Besides, we already know it can find the profile. If it could not do that, then why are we bothering to write-protect profile files? I don't know about protection from Internet applications, but as far as I can tell, a random directory name offers NO protection against locally run malware. It probably would protect against some friendly applications, however.

You might have better luck with installing Firefox and the profile in an unexpected place, but I don't know what information it could get from the Registry.

Thanks for all the information. It's going to get put to good use on my computer.

[steviex]

^^ Thanks for the clarification Frank, and the answer to my question (Even though I got it wrong !)

[Grist]

Be aware, however, that in theory (?) rogue plugins could try to install directly into the Firefox application plugin folder. This could be prevented (?) by having the Firefox application in an unexpected location, i.e. not C:\Program Files. This is easy when, as I do, using .zip builds, but may be quite a chore for installers. Suggest we cross this bridge when/if we come to it. Meanwhile, just keep an eye on the Plugins section of the Addons Manager for suspect plugins.

On Windows, some applications use the "Plugins" value in the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Mozilla Firefox x.x.x\extensions

Quicktime is one application that uses that value to find the plugins path. That key is added by installers only so zip build users don't have to worry about it.

One minor drawback: If that value is removed or changed, Quicktime browser settings will not work because it needs that value to copy and remove different plugins. However, the plugins can be manually copied from the Quicktime program directory after changes are made.

Edit: I'm not sure but I think an auto update will add that key regardless of whether a zip build is being used or not.

[anjalip222]

Instead of complicated maneuvers, why not simply empower the user to disable/uninstall the extension or plug-in of choice?

[VanillaMozilla]

The user is empowered already. But this user didn't know that an unwelcome plugin had been installed. I look at the process list and I have no idea where most of that crap came from. There's just all kinds of garbage that someone is always trying to install on my computer, and the more I can lock it down, the better. Thanks, Frank, for the information.

[Alice]

Some "add-ons" installed by other applications are actually new Firefox components and don't appear in the Extensions or Plugins lists.

Norton 360 and Norton Internet Security include a "Phishing Protection" feature which, from what I've gathered, is enabled by default. This installs the file "coFFPlgn.dll" directly into the Firefox program components folder and adds the Norton anti-phishing toolbar to Firefox. The Norton toolbar doesn't appear in the Firefox "Extensions" or "Plugins" lists so it's not so easy for users to figure out how to remove it, much less block its installation.

Ref:
http://kb.mozillazine.org/Uninstalling_toolbars#Other_solutions
https://bugzilla.mozilla.org/show_bug.cgi?id=452469
http://kev.deadsquid.com/?p=663

[Frank Lion]

Edit: I'm not sure but I think an auto update will add that key regardless of whether a zip build is being used or not.

That would seem to be correct, in my case. Many thanks for the other information as well, most useful.

...The Norton toolbar doesn't appear in the Firefox "Extensions" or "Plugins" lists so it's not so easy for users to figure out how to remove it, much less block its installation.
]

We shall see. For users of both Firefox and Norton *shudder* would a preventative approach work?

On a standard MS install, navigate to C:\Program Files\Mozilla Firefox\components\ and see if coFFPlgn.dll already exists. If it does, then delete it (with Firefox closed, of course ) and then, even if it doesn't exist then assume that one day it will and in both cases proceed to do the following, from your Ref. here - http://kb.mozillazine.org/Uninstalling_ ... _solutions

...create an empty text file (e.g., with Notepad), rename it "coFFPlgn.dll" and change the properties to "read-only"

..and throw the resultant file into the components folder. If dumb old Norton stumbles it's way later on to that folder, it will just think it has already put it there and , er, forgotten about doing it and will just amble off again.

Would that preventative approach block the initial installation attempt, do you think?

BTW I see that you have hastily tidied up the KB Plugin scanning link.

[VanillaMozilla]

Norton 360 and Norton Internet Security... installs the file "coFFPlgn.dll" directly into the Firefox program components folder and adds the Norton anti-phishing toolbar to Firefox.

Grrr.... Do they fully inform users, or do they just do that gratuitously?

[Alice]

Norton 360 and Norton Internet Security... installs the file "coFFPlgn.dll" directly into the Firefox program components folder and adds the Norton anti-phishing toolbar to Firefox.

Grrr.... Do they fully inform users, or do they just do that gratuitously?

They just go ahead and add it, as far as I can tell from what I've read (I don't use Norton myself).

More here on Norton 360 and Firefox:
http://support.mozilla.com/en-US/kb/Configuring+Norton+360

[Alice]

from your Ref. here - http://kb.mozillazine.org/Uninstalling_ ... _solutions

...create an empty text file (e.g., with Notepad), rename it "coFFPlgn.dll" and change the properties to "read-only"

..and throw the resultant file into the components folder. If dumb old Norton stumbles it's way later on to that folder, it will just think it has already put it there and , er, forgotten about doing it and will just amble off again.

Would that preventative approach block the initial installation attempt, do you think?

Yeah, it would probably work but my point was that other software can do similar stuff and who could anticipate it all? See comment 45 in bug 452469 which mentions, Both Norton and Zone Alarm are using a toolbar to interact with the user. Probably it also places a dll file into the components directory which could block the access to places.sqlite.

BTW I see that you have hastily tidied up the KB Plugin scanning link.

Just some minor cleanup and updated info (SeaMonkey 1.1 and above no longer create a Common Files\mozilla.org\GRE folder).

[VanillaMozilla]

They just go ahead and add it, as far as I can tell from what I've read (I don't use Norton myself).

Then once again I will advise users to dump it. In my opinion, grounds for dumping security products include:

1. Support personal making false negative claims about Firefox.
2. Tinkering with program setup.
3. Installing add-ons to other programs without clear notice (fine print doesn't count).
4. Creating performance problems for other programs.

[Frank Lion]

... but my point was that other software can do similar stuff and who could anticipate it all?

Yes, and I very much accept that point.

Most of this thread has been dealing with blocking what is, for want of a better term, 'IrritantWare', be that in extension or plugin form, i.e. 'MyCPUHog' plugin, etc. Real malware still should, as Vanilla mentioned, be dealt with by our conventional security programs, antivirus, Spybot, Adaware, etc.

You have now introduced a somewhat ironic twist on all this. Think about it, why are we really all so vigilant about virii and malware? Yes, the personal information side, but isn't it also because we know that malware can totally wreck working programs and entire Operating Systems?!

Consider then, this version of the Norton Antivirus program that has deliberately introduced an element into the core of the Firefox application, that has effectively wrecked that program by rendering the bookmark and history side useless. What is that, if not malware? Perhaps Norton should add themselves to their own malware definitions list!

Yes, my blocking suggestion was a reasonable one...for the people that happen to come across it here, but this Norton/ZoneAlarm/others stuff needs a proper Mozilla fix - and soon.

[Elfguy]

While this has some use, I would argue that it's useless to most people. Users won't go write protect files and disable all plugins to prevent a potentially unwanted application from hooking into Firefox. I still think Firefox itself needs to keep track of its installed plguins/extensions in some type of encrypted or signed file, and any time the browser is started and it detected a new one, it warns the user about it. That I think is the right way to do it, since that doesn't add any step for users or plugin makers, but it does solve the problem since now users get a warning any time a new extension or plugin has been installed without direct user intervention.

[Frank Lion]

While this has some use...

Maybe I should point out that this is a technical thread for technical users, who wish to block the potential installation of unwanted extensions and plugins. In addition, I should mention that no one here has suggested disabling all plugins anywhere and certainly all my required plugins are fully operational, as before.

People who are unwilling or unable to even attempt the suggestions given above, can patiently wait for your suggested fix that overtly warns them after the installation of unwanted extensions and plugins has been made. A fix, that you have already pointed out, has been marked as WONTFIX by the devs.