Bundled NPAPI Plugins are always globally accessible

RESOLVED INCOMPLETE

Status

()

Core
Plug-ins
--
enhancement
RESOLVED INCOMPLETE
6 years ago
8 months ago

People

(Reporter: Kyle L. Huff, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
User Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.32 Safari/535.7

Steps to reproduce:

1. Install an extension which provides a bundled NPAPI Plugin
2. Access a page that references that plugins mime-type
3. Execute methods exposed by the plugin


Actual results:

The plugin loads regardless of the user or extension developers desire to make the plugin accessible only to the extension that provides it.


Expected results:

Extensions should not automatically make bundled NPAPI plugins globally accessible as it creates issues related to user security and can cripple functionality.

For example, I have developed an extension which uses a bundled NPAPI plugin to provide access to a user-level system resource; however in Firefox I am not able to indicate that only the providing extension can access those methods and the NPAPI plugin is made globally available to other extensions and can also be instantiated on a malicious website.

Furthermore, I imagine it is possible that a malicious extension could provide an NPAPI plugin that mimics the functionality of a trusted plugin - such as Adobe Flash - and trick the user into exposing sensitive information.

Chromium for example has a manifest flag that allows bundled plugins to be either public or private to the extension that provides it, which removes the necessity for the otherwise browser agnostic NPAPI Plugin to have browser and extension subsystem specific logic that enforces such a rule.
I don't know why you would use NPAPI for anything other than showing content. If you're looking for an easy way to access system libraries, js ctypes is probably what you're looking for: https://developer.mozilla.org/en/js-ctypes.

Moving to Core > Plugins, since there is where such a change would be considered.
Component: Extension Compatibility → Plug-ins
Product: Firefox → Core
QA Contact: extension.compatibility → plugins

Comment 2

6 years ago
Actually showing content is probably the least common use case overall, at least of those that I encounter who use the FireBreath framework (Kyle is one of them). js-ctypes may allow someone to do with an extension what they might otherwise use a plugin / c++ for, but it would not be portable between browsers.  Conversely, a NPAPI plugin can be written to work on all NPAPI-compliant browsers, which is pretty much anything but IE, and a FireBreath plugin will work on IE as well. The advantages are huge in terms of development cost. 

In addition, many plugins (and I think Kyle's is included here) use existing C++ libraries that you can't emulate with js-ctypes or that would be a lot of work to port to javascript. Some interface with USB devices (and yes, I know you're working on something to solve that issue), some provide unsandboxed access to the filesystem, some provide more powerful upload tools, etc.

The biggest use case for this feature is security-sensitive extensions; with a NPAPI plugin as it currently works in Firefox, there is no reliable way to restrict access to the plugin to only a specific extension, or to a specific page, and that makes it difficult to provide features in your plugin without opening dangerous security holes.  However, since it's the best and/or easiest option, many are doing it anyway.  By providing a method to embed a NPAPI plugin into an extension and enforce that it can *only* be used by that extension, you provide a way for plugin developers to better avoid becoming the cause of security holes and giving plugins an even worse name than they already have.

Chrome supports this feature, and I have users frequently ask me about ways to do it with Firefox.

Comment 3

6 years ago
This is a valid enhancement request. I'd like this to be done, but I doubt that it's very high-priority. I will at least write a feature page so that blizzard and product drivers are aware and can make priority decisions.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: x86 → All

Comment 4

6 years ago
https://wiki.mozilla.org/Features/Platform/Chrome-only_Plugins

Comment 5

8 months ago
Resolving old bugs which are likely not relevant any more, since NPAPI plugins are deprecated.
Status: NEW → RESOLVED
Last Resolved: 8 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.