Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#3547 closed defect (fixed)

Disable all plugins but flash

Reported by: mikeperry Owned by: mikeperry
Priority: High Milestone: TorBrowserBundle 2.2.x-stable
Component: Firefox Patch Issues Version:
Severity: Keywords: MikePerryIteration20110911 backport-to-mozilla tbb-2.2.32-4
Cc: StrangeCharm, erinn Actual Points: 3
Parent ID: #2871 Points: 2
Reviewer: Sponsor:


We need to patch Tor Browser to disable all plugins but the flash plugin. The addon manager has the ability to do this, but it is not exported to XPCOM, so we must write a patch in C++.

We should do this instead of mucking with the Firefox plugin search paths in Tor Browser.

Child Tickets

Change History (18)

comment:1 Changed 9 years ago by mikeperry

There are a few other ways to do this. We can try to change the plugin.scan pref in all.js during build, and/or alter the scanning process. This may be better, because it would stop plugins from being able to run executable code as the Firefox browser. It is quite possible that AV plugins will do something crazy that can't be disabled/undone, like actually patching the Firefox imports..

Some relevant urls:

comment:2 Changed 9 years ago by mikeperry

Actually, the current correct line number for AddonManager.jsm is:

comment:3 Changed 9 years ago by mikeperry

Reminder to self: Once this is done, we should remove the enabledScopes pref setting in TBB.

comment:4 Changed 9 years ago by mikeperry

Points: 8

comment:5 Changed 9 years ago by mikeperry

Some notes:

The meat of the work is done in nsPluginHost::ScanPluginsDirectory().

Apparently there is a blocklist service we *could* use from script (;1), but it is only called *after* the plugin is already loaded. If the pref plugins.unloadASAP is set, the plugin will be forcibly "unloaded" after the blocklist is checked.

However, if our goal here is to prevent these plugins from loading in the first place on the assumption that AV plugins, weird MS plugins, and censorship filter plugins will all directly try to patch the Firefox binary in memory as soon as they are loaded, the blocklist service is then insufficient.

I would guess that mozilla would accept a patch to the blocklist service that would allow us to block a plugin based on plugin info *before* loading, but this requires a lot of plumbing. The mime type and description fields in nsPluginInfo (and therefore nsIPluginTag) are filled in using NPAPI calls against the library.

As for minimal hacks... stay tuned..

comment:6 Changed 9 years ago by mikeperry

In terms of creating a diff with the minimum possibility for conflicts, the place to hack is nsPluginFile::GetPluginInfo(). This function is the function that assembles info about the plugin *and* loads it.

In a sane world, we could safely refactor this function into two pieces: one that gets all the basic info before actually loading the library into the process space, and one that loads the plugin to get the rest of the info. We could then call the blocklist service in between these two calls.

However, this is likely to hit conflicts in future Firefox versions unless it is merged immediately.

The dirty hack then is create a function that we call from nsPluginFile::GetPluginInfo(). This function would then just do something dumb, like strstr each fName and/or fDescription for something that looks like flash or gnash. If it finds that substring in those fields, it can return ok.

Otherwise, we can just make nsPluginFile::GetPluginInfo() return NS_ERROR_FAILURE and the plugin will not load.

The simplicity of this dirty hack appeals to me. I think we should do it.

comment:7 Changed 9 years ago by mikeperry

Points: 82

If we take the dirty hack route, this should be easy. Adjusting points accordingly.

comment:8 Changed 9 years ago by mikeperry

#3133 was dupped to this.

comment:9 Changed 9 years ago by mikeperry

Keywords: MikePerryIteration20110911 added

comment:10 Changed 9 years ago by mikeperry

Cc: StrangeCharm added

comment:11 Changed 9 years ago by erinn

Cc: erinn added

comment:12 Changed 9 years ago by StrangeCharm

Keywords: backport-to-mozilla added

comment:13 Changed 9 years ago by mikeperry

Actual Points: 2
Resolution: fixed
Status: newclosed

erinn: This is done in mikeperry/bug3547, but it needs testing on Windows and MacOS.

StrangeCharm: You might not want to backport this exact patch. Mozilla will probably want to properly refactor nsPluginFile::GetPluginInfo() to consult the blocklist, but not all info will be available at that point, so you might want to debate on a new API or something.

comment:14 Changed 9 years ago by erinn

Resolution: fixed
Status: closedreopened

So far I have only tested this on MacOS, and I think I would say it partially works. I removed enabledScopes from the prefs.js, and indeed, all plugins other than flash do not appear. But flash also doesn't appear. What other useful information can I give you about this?

It's currently building on Windows, I will report back when I have more information about that.

comment:15 Changed 9 years ago by mikeperry

Actual Points: 2

Heh, we got Mac OS working, but it turns out windows is broken.

Guess this isn't done after all..

comment:16 Changed 9 years ago by mikeperry

Actual Points: 3
Resolution: fixed
Status: reopenedclosed

Woo hoo. It was just a stray pref on windows.

comment:17 Changed 9 years ago by erinn

Keywords: tbb-2.2.32-4 added

comment:18 Changed 9 years ago by erinn

Keywords: MikePerryIteration20110911, backport-to-mozilla, tbb-2.2.32-4MikePerryIteration20110911 backport-to-mozilla tbb-2.2.32-4
Note: See TracTickets for help on using tickets.