User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11) Gecko/20070914 Firefox/18.104.22.168 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) Gecko/20070914 Firefox/126.96.36.199 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...
Summary: docShell.allowPlugins not enforced for direct links → docShell.allowPlugins not honored for direct links
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.
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.
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
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.
Assignee: nobody → jschoenick
Status: NEW → ASSIGNED
Component: Security → Plug-ins
OS: Windows XP → All
Product: Firefox → Core
Hardware: x86 → All
Was likely fixed by bug 767638
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.