Closed Bug 686134 Opened 13 years ago Closed 12 years ago

Addons can run arbitrary code and cause security bugs

Categories

(Core :: Security, defect)

Product:
Core
Component:
Security
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED DUPLICATE of bug 219180

People

(Reporter: briansmith, Unassigned)

References

Details

(Keywords: sec-want, Whiteboard: [sg:want?])

+++ This bug was initially created as a clone of Bug #686095 +++ +++ This bug was initially created as a clone of Bug #644640 +++ From bug 644640 Comment 2: "One overarching point is that because FF extensions run arbitrary code, they can always cause security bugs. That's the tradeoff you get for being an extensible browser. If we wanted an API that implemented allegedly benevolent dictatorship, we'd be coding for Chrome ;)." We should put the user in control of what addons can do, like we are doing for open web apps. In fact, open web app installation and addon installation are almost exactly the same thing as far as user perception is concerned; we should make sure the security models are similar.
Moxie also noted the problem in bug 644640 comment 3: "Addons can execute arbitrary code, and the potential for malicious addons is somewhat infinite."
Um... I don't see what you're trying to accomplish with this bug. Extensions by design can do anything. The only way to stop this would be to flat out eradicate support for extensions and only allow Jetpack/Addon SDK APIs (and force all thier libraries to be included by default to stop the bloat they currently cause in XPIs). As has been said in many places before, this is why AMO has a lengthy security and policy review process for addons, why there's a warning not to install untrusted addons, and why we have an addon blocklist (that doesn't get used quite enough). The best you can hope for might maybe to ban all binary executables in extensions, which has been discussed before, but even that will alienate quite a few extension developers and users.
(In reply to Dave Garrett from comment #3) > Um... I don't see what you're trying to accomplish with this bug. Extensions > by design can do anything. Right. I think the current design is problematic and we need a new design that aligns with the permissions model that we are designing for open web apps. My understanding is that the line between open web apps and extensions is going to blur until it disappears. > The best you can hope for might maybe to ban all binary executables in > extensions, which has been discussed before, but even that will alienate > quite a few extension developers and users. For binary addons, there are other alternatives that have been implemented by others, such as Google's Pepper2 and NaCL projects. For JS addons, I think we need to work on refactoring our APIs so that they are all compatible with the JetPack security model.
(In reply to Brian Smith (:bsmith) from comment #4) > Right. I think the current design is problematic and we need a new design > that aligns with the permissions model that we are designing for open web > apps. My understanding is that the line between open web apps and extensions > is going to blur until it disappears. I don't see that happening at this rate. Extensions are simply not content. They alter the browser itself and thus have access and abilities in the same realm of the browser. > For JS addons, I think we need to work on refactoring our APIs so that they > are all compatible with the JetPack security model. Could you please be more specific: what APIs? Jetpack is one thing, but will not be able to cover every extensions' needs. The APIs provided via XPCOM interfaces are an entirely different matter. If a way to detect explicitly which addons are accessing what and apply some sort of security profile that would be great, but as-is extensions are mixed into things way too much. We can't even tell how much memory an addon uses yet (see bug 671352 for a start on that).
personally i think addons being full privileged is key to their success, a lot of engineering teams also rely to some degree on being able to quickly prototype features as add ons. Firefox's addon model additionally is a key differentiated with Chrome. This bug is 'working as designed' in my opinion. I also totally disagree that the security model for add ons and web apps should be the same, due to the AMO review process as well, and what i believe are differing use cases.
(In reply to Ian Melven :imelven from comment #6) > personally i think addons being full privileged is key to their success, a > lot of engineering teams also rely to some degree on being able to quickly > prototype features as add ons. Firefox's addon model additionally is a key > differentiated with Chrome. This bug is 'working as designed' in my opinion. > > I also totally disagree that the security model for add ons and web apps > should be the same, due to the AMO review process as well, and what i > believe are differing use cases. and not just MoCo engineering teams, but more importantly community members can provide functionality in add ons that would probably never make it into an official firefox release also.
(In reply to Brian Smith (:bsmith) from comment #0) > In fact, open web app installation and addon installation > are almost exactly the same thing as far as user perception is concerned; we > should make sure the security models are similar. What? I'm not familiar with "open web apps", but the addon dialog says, "Install add-ons only from authors whom you trust. Malicious software can damage your computer or violate your privacy." I can hardly imagine a clearer statement of the addon security model than that. Dropping support for fully privileged addons would be a disaster. Users who currently rely on addons that by their nature require full privilege (Firebug, NoScript, Greasemonkey, etc.) will have to fork the browser. IMO, this bug is INVALID, and work on developing models for lesser-privileged browser components and porting existing addons to such models should proceed separately.
No longer blocks: 686095
The only way to "fix" this bug would be to abandon addons (presumably) in favour of Jetpack, and disallow them. That would remove one of Firefox's major points of differentiation from e.g. Chrome (which does things in the "limited API only" way). In the past, even the suggestion that this might be happening has caused community outcry. Here's some of the damage control: http://weblogs.mozillazine.org/asa/archives/2010/01/firefox_addons.html So I'm pretty certain this is a WONTFIX. Gerv
While I think (and have said in the past) that we desperately need to get away from XPCOM interfaces -- in general, not just for extension hook points -- I agree with Gerv that we do *not* want to limit what extensions can do. It is my hope that the old extension model goes away because Jetpack (or something like it) has become capable of doing everything it did. [One exception to that: I would be in favor of phasing out all support for *binary* add-ons, starting now, even if it temporarily removes possibilities.] ... This bug was forked from bug 644650, which is asking for a *new* hook point to override the standard certificate validation mechanism. I'm not sure how "we want to experiment with alternatives to the CA mess" morphed into "OMG extensions can break the user's security." The CA mess isn't doing right by our users. I'm very much in favor of getting that new hook done and landed.
Whiteboard: [sg:want?]
There seems to be more or less an agreement that binary addons need to go, especially with the rapid releases making it less practical, so it might be time to file a new bug to track just that and plan out how to proceed.
For any change like this to be contemplated, it would need discussion a heck of a lot more public than this bug. If I understand this proposal correctly, it would alter our add-on ecosystem in pretty fundamental ways. As a meta-point, our add-ons community is spending a lot of effort working on ways to make add-on maintenance and development easier, particularly in the context of rapid release. We've made great progress there, and I would hate for some member of that community to see this bug and infer that A Decision Had Been Made. So, to any wayward passersby, please understand that this is a lively (and perhaps misplaced) technical what-if discussion, not at all a fait accompli.
Filing a bug and fixing a bug are two different things. I filed this bug because when we discuss this, somebody always asks "did you file a bug?" This is the only way we have to track issues like this. I agree 100% with johnath that there will have to be a very big, very open discussion to decide if/how we decide to start applying the principle of least privilege to extensions. We are going to be having a big discussion regarding permissions models for WebAPIs and open web apps. One of the points that has been brought up is that a website will be able to subvert the permission model for WebAPIs and open web apps by having the user install an extension instead of an open web app, since it seems likely there won't be a very clear (to the user) UX difference between installing an open web app and installing an extension. The issue of unclear and unnecessary (to the user) distinctions between various kinds of add-ons was also brought up by the UX team during Friday's UX session at the all-hands.
(In reply to Brian Smith (:bsmith) from comment #15) > One of the points that has been brought up is > that a website will be able to subvert the permission model for WebAPIs and > open web apps by having the user install an extension instead of an open web > app, since it seems likely there won't be a very clear (to the user) UX > difference between installing an open web app and installing an extension. We could, um, make such a clear difference. The addon install dialog already has a strong warning message and a timeout, in view of its sensitivity. If open web apps are properly sandboxed, their install dialog won't need such measures. If the addon dialog needs to be even more distinctive, make the text red or add a diagonal striped background or something.
Dup of bug 219180?
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.