401296 - docShell.allowPlugins not honored for direct links

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect)

Description

[Mike Perry]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7

Currently the only way for a user to really disable plugins in Firefox is to install an extension that toggle the docShell.allowPlugins attribute. Unfortunately, this attribute is not enforced if the user either redirected to (or directly clicks on) a plugin-handled mime-type. There are many security reasons why a user would want to disable plugins selectively, including but not limited to attacks such as Dan Kaminsky's Flash/Java firewall tunneling exploits, and usage over either instututional proxies, and the Tor Project.

Reproducible: Always

Steps to Reproduce:
1. Install an extension that disables plugins with docShell.allowPlugins (such as Torbutton-alpha at http://torbutton.torproject.org/dev or PrefButton) 
2. Visit a plugin-handled link, or visit a site that has a meta refresh to a plugin handled link (*.swf, *.pdf, etc etc)
3. Watch the plugin load despite having been disabled.
Actual Results:  
Plugin loads.

Expected Results:  
Plugin should not load.

Currently various hacks exist to block this behavior. NoScript and Torbutton-alpha both do the request.cancel() call, but this does not actually stop the plugin from loading. In particular, AcroRead still parses the URL arguments and performs some network operations before it can be cancelled, and cancelling it can even hang the browser in some situations...

Comment 1

[Brandon Sterne (:bsterne)]

Attachment: Test extension sets allowPlugins = false

Comment 2

[Brandon Sterne (:bsterne)]

Attachment: Flash content for following testcase

Comment 3

[Brandon Sterne (:bsterne)]

Attachment: Testcase for use with test extension

Comment 4

[Brandon Sterne (:bsterne)]

I created a test extension and test page that demonstrates the bug.  The test extension adds an item to the Tools menu that when clicked sets docShell.allowPlugins=false for the selected tab.

To reproduce:
1. install Test extension
2. open the test case (3rd attachment) and note that the Flash video loads
3. select "Disable plugins" from the Tools menu
4. re-load the test case and note that the Flash video does not load
5. click the link in the test case to browse directly to the Flash video.  Note that the video loads even though allowPlugins is set to false.

Comment 5

[Mike Perry]

Turns out there is a hidden pref that may address this. plugin.disable_full_page_plugin_for_types seems like it should prevent the direct-link load case for a list of mime-types, but I have not yet investigated it deeply to verify it handles all cases.

Comment 6

[shawn.sumin]

The Tor Project / Electronic Frontier Foundation is paying to have this bug
fixed.

"If you know C++ and/or Firefox internals, we should be able to pay you for
your time to address these issues and shepherd the relevant patches through
Mozilla's review process."

Source:
https://blog.torproject.org/blog/web-developers-and-firefox-hackers-help-us-firefox-4

Comment 7

[John Schoenick [:johns]]

Does this issue still occur?

The full page plugin cleanups in bug 767638 should've removed the last bits of "full page" plugins being a special case, and I wasn't able to reproduce this locally.

Comment 8

[John Schoenick [:johns]]

Was likely fixed by bug 767638