219180 - Limited-privilege extensions (was: security on Extensions is seemingly non-existent)

Status: RESOLVED FIXED

(Core :: Security, enhancement)

Description

[Kevin Smith]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Build Identifier: 

Information on limitations of extensions is not readily available. It would 
seem that extensions can, at the current time, access various parts of the 
system without control. It would be appropriate to include a rights system to 
enable the user to control rights available to the extension. Extensions which 
do not require access to the system would not be given access to that by the 
user (eg. a tab-enhancement extension) whilst other extensions could be given 
rights (eg. an extension to enhance local file browsing).

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Boris Zbarsky [:bzbarsky]]

This needs the introduction of the concept of an untrusted part of the browser.
 At the moment, all parts of the browser per se (and extensions become such once
they are installed) are assumed to be trusted (if you don't trust it, don't
install it).

The issue, of course, is that the vast majority of extensions (including the
ones that "just change tab behavior"), _do_ need full XPConnect priveleges.  For
example, such priveleges would be required to set and read preferences...

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

preferences are not an ideal example:
UniversalPreferencesRead 	Read preferences using the navigator.preference method.
UniversalPreferencesWrite 	Set preferences using the navigator.preference method.
(from
http://www.mozilla.org/projects/security/components/signed-scripts.html#privs-list,
though I don't know if moz implements that)

Comment 3

[Brian 'netdragon' Bober]

This comment might be better for another bug, I'll let the bug reporter be the
judge of that:

Another extensions security issue is that its too easy for Spyware/trojan
applications to install themselves into Mozilla as extensions without the user
actually doing it.

Example: User downloads Kazaa, spyware application plops its extension in
without using Mozilla.

Can we do things like encrypt the extension registry and have ways to detect if
applications already on the disk have made modifications to the Mozilla
installation without it being through the user manually installing the
extension? Can we make sure extensions can always be removed by the user through
the appropriate UI?

I know for trojan and spyware writers, where there is a will, there is a way.
Still, with constant code changes, etc, we can make it so people cannot just
hack extensions into Mozilla like they do with activeX controls in Internet
Explorer. The idea is to make it very very hard for them to do so, so hard its
not really worth it.

Seeing my little brother's Internet Explorer browser loaded up with Spyware, I
gave him Firebird. He could browse again! :-)

I really hope Mozilla never gets like that. :-(

There is a big discussion on this in:
http://forums.mozillazine.org/viewtopic.php?t=39266

Extension security is something we really need to think about, and the sooner
the better.

Comment 4

[Brian 'netdragon' Bober]

Bug 262762 - Method to keep adware and malicious extensions and plugins from
being added without our knowledge

Comment 5

[Jesse Ruderman]

*** This bug has been marked as a duplicate of 346960 ***

Comment 6

[Jesse Ruderman]

Hmm, maybe not.

Comment 8

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

I may be wrong, but the user in comment #3 did not get confused with plugins?

PS: in the duplicate Bug 247684 there's some interesting examples.

Comment 9

[Jesse Ruderman]

The Mozilla community has already identified two large classes of extensions that can be implemented on a limited API: user scripts (Greasemonkey) and user style sheets (Stylish).  If we want to get users out of the habit of installing full-privilege extensions, maybe we should start by incorporating something like Greasemonkey and Stylish into the extension manager.

Comment 10

[Jesse Ruderman]

The Jetpack add-on SDK allows extensions to be partitioned into sandboxed scripts with different privileges.

See bug 89016 for supporting Greasemonkey-style user scripts, and bug 774065 for supporting bookmarklet-style user script buttons better.

Comment 12

[Renato Silva]

One example of this lack of privilege control is download in private browsing. I'm working on an add-on that needs to save current page with nsIWebBrowserPersist.saveURI() [1] as an implementation detail. However, that qualifies as a "download" and thus it is ignored by private browsing. I thought passing a privacy context to saveURI would save the file "to RAM" or delete it on exit, but it has no effect.

Not that the API should become more bureaucratic, just more secure. In my example, not that I would need twenty more lines of code for downloading stuff, just that it will be automatically privacy-aware (e.g. emulating download on memory or something). Additionally, when installing add-ons, Firefox could allow advanced users to check what permissions they use (e.g. "this add-on can perform silent downloads"), and mainstream users to be aware about potential issues (e.g. "this add-on is not safe for private browsing").

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIWebBrowserPersist#saveURI%28%29