Closed Bug 36375 Opened 26 years ago Closed 26 years ago

Scripting of <embed> plugins should not require signed scripts and .jar files

Categories

(Core :: Security: CAPS, defect, P3)

Product:
Core
Component:
Security: CAPS
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: sean, Assigned: security-bugs)

Details

(Whiteboard: [nsbeta2+])

Attachments

(1 file)

proposed fix
5.57 KB, patch
Details | Diff | Splinter Review
Content developers use javascript to control plugins which are instantiated into pages using the <embed> HTML tag. In the old world, plugins were reflected into the JS namespace by way of LiveConnect. Scripting of plugins did not require signed scripts or .jar files. Now, XPConnect is responsible for that reflection (see http://bugzilla.mozilla.org/show_bug.cgi?id=32150 ). Per security requirements documented at http://www.mozilla.org/projects/security/components/design.html access to XPConnect components is limited - especially from http URIs. However the document shows that plugins were not considered: "Limited access to XPConnect components--most components will not be accessible from web content." Of course, XPCOM plugins are reflected via XPConnect and are only accessible from web content. http://bugzilla.mozilla.org/show_bug.cgi?id=858 shows that plugins are considered a special case when it comes to Javascript and security: 'plugins are caveat-downloader' (a comment by brendan@netscape.com on 9/24/98). As I understand it, now that plugins are reflected via XPConnect, any script (or page that contains JS) which needs to invoke plugin methods is required to be wrapped in a .jar file if it will be accessed via http. For example, http://www.beatnik.com stays the same for Navigator 3/4 and IE but for Mozilla it will need to be jar:http://www.beatnik.com/index.html. Entire sites will need to be duplicated in .jar files if they make use of plugin scripting. This is not a good thing... A possible way to address this is through the addition of an 'Enable Scripting of Navigator Plugins' pref to the 'Advanced' preferences UI and modification of http://lxr.mozilla.org/seamonkey/source/caps/src/nsScriptSecurityManager.cpp . I suggest that the pref be enabled by default (same as the 'Enable Javascript in Navigator' pref). Three methods in nsScriptManager.cpp (CanCallMethod, CanGetProperty, CanSetProperty) could be modified as follows (they have identical bodies): - return CheckXPCPermissions(aJSContext); + nsresult retval = CheckXPCPermissions(aJSContext); + if (retval != NS_OK) + retval = CheckXPCPermissionsPlugin(aObj); + return retval; This change would require something like the following: + #include "nsIPluginInstance.h" + + // this is called after a call to CheckXPCPermissions returns an access + // denial when called from CanCallMethod(), CanGetProperty() or CanSetProperty() + static nsresult + CheckXPCPermissionsPlugin(nsISupports *aObj) + { + // see if the wrapped object implements the nsIPluginInstance interface + nsCOMPtr<nsIPluginInstance> plugin = do_QueryInterface(aObj); + if (plugin) + { + // if it does, then check the user's "security.checkpluginxpconnect" pref + // note that this is independent of "security.checkxpconnect" + nsresult rv; + NS_WITH_SERVICE(nsIPref, prefs, kPrefServiceCID, &rv); + if (NS_SUCCEEDED(rv)) + { + PRBool enabled; + if (NS_SUCCEEDED(prefs->GetBoolPref ("security.checkpluginxpconnect", &enabled)) + && !enabled) + { + return NS_OK; + } + } + } + return NS_ERROR_DOM_XPCONNECT_ACCESS_DENIED; + } The last thing needed for this particular solution would be the changes required to make the new pref available on the Advanced setting page.
Added myself to the cc list.
1) I agree with everything sean said. 2) Only caveat: in fact, unless the new architecture requires it for some reason, there's no reason we have to offer end users the ability to turn off scripting of plug-ins in Mozilla/Netscape 6 if we didn't in Navigator 4. That would be an enhancement (increased end user control over security model) and we're trying to avoid extra enhancements at this point. So my first preference would be simply to enable scripting of plug-ins by default as we did in Nav4; if they want to turn that off, they can do so by turning off JavaScript, just as they could in Nav4. But regardless of how that issue is resolved, we definitely need to enable scripting access to plug-in APIs by unsigned JavaScript in Mozilla/Netscape 6 as was possible for Navigator 4. One of the goals for the Mozilla Plug-in API is to provide backward compatibility for existing content (including LiveConnect calls in JavaScript) once plug-ins are upgraded to the Mozilla Plug-in API. This is vitally important for the content and plug-in developer communities. Marking nsbeta2 keyword.
Keywords: nsbeta2
Sean, I'm glad you came up with this. I was puzzling a little the other day with how to solve this problem and came up with the same sort of notion myself. But, I did n't actually implement it. It is still limiting in that it only allows calls into the plugin to the actual pluingInstance object (or aggregated objects). This is not necessarily a bad thing. But it should be documented so that people are not surprised when their other native objects created in the plugin are not callable from JS even if the pluginInstance "hands them over" to the JS code. And, unfortunanately, It does not 'freeup' calls to the standard xpconnect JS-side infrastructure; i.e. you can't use stuff that hangs off the 'Components' object that you would normally be able to use. The seamonkey security stance to xpconnect has been very binary up to now. We could start to extend the security manager's policy toward xpconnect so that it allows more of the safe 'Components' object activities by default. This would allow for more natural use of xpconnect here and eventually elsewhere. Anyway. I think that what you suggest ought to be checked in.
That said... This code should live inside of CheckXPCPermissions rather than outside of it. The JS_SetPendingException stuff matters. That exception should not be set if the return value is going to be overridden. CheckXPCPermissions just needs to get handed an additional param at each call site.
When the proposed changes are made, will we have achieved 100% backward compatibility with existing plug-in content that calls LiveConnect (once the plug-in has been upgraded to the Mozilla Plug-in API)? The technical details here are beyond me but this is the degree of backward compatibility we must achieve or we will break existing content *even after* plug-ins have been upgraded. Setting M16 and marking 4xp. It's vital we get this fixed by FCS. This strikes me as a backward compatibility "bug" rather than a new feature, so maybe the fix to the bug can go in post-nsbeta2 if necessary, but obviously it would be good to have this in by nsbeta2 if possible.
Keywords: 4xp
Target Milestone: --- → M16
Erik, I don't think there ever *was* a plan for 100% backwards compatibility of scripting plugins. There is no plan I know of to have any means in place to support reflecting either a plugin-spcified Java class (ala 4.x) or any particular xpcom interface directly into the namespace of the named plugin as 4.x did. What I think we're talking about here is a reasonable alternative mechanism that allows sufficient functionality without imposing painful requirements on pages that script plugins. But, it will still require those pages to have slightly different code.
I'll add an attachment with a diff of changes modified per comments from ekrock and jband. The diff includes changes that norris notified me he was going to checkin soon (removal of TEMPORARY block from CheckXPCPermissions) - so this checkin should wait for him (or the block can be added back in).
Attached patch proposed fix — — Splinter Review
This looks good to me. Norris, what do you think? Can you get this checked in?
Bulk reassigning most of norris's bugs to mstoltz.
Assignee: norris → mstoltz
This looks good to me. Mitch, what do you think? Can you get this checked in?
This patch looks OK to me, provided you, the interested parties, think this doesn't open any gaping security holes. We're talking about allowing any script to access any object which implements the nsIPluginInstance, so we're assuming that either plugins can't do anything dnagerous, or else they can and it's "caveat downloader." If everyone's OK with this, I'll check this in.
Status: NEW → ASSIGNED
Norris is worried about this...let's distinguish between plugins and scripts which access the plugin. You may trust the Shockwave plugin, but not trust www.hacker.com to interact with Shockwave via a script. Comments?
If you don't trust www.hacker.com, then you would want to disable all navigator javascript - not just scripting of plugins.
Plug-ins are native binaries. Netscape by definition has always made no guarantees about the degree of security or vulnerability to attack of native binaries; that's the responsibility of the creator of the binary. (Browser vendors can't make any guarantees about the security of native binaries because (1) for starters, we don't have the source code for the binaries to analyze, and (2) it's their product, not ours.) Anyone who downloads and installs a native binary is making a decision to trust the creator of the binary. That includes trusting that the binary creator didn't supply API calls that will do things the user doesn't want without getting the user's permission. e.g. if the foobar plugin from Foobar.com offers a JavaScript-callable eraseHardDrive() method, then Foobar.com had better have made sure that the method pops up a confirmation alert for the user. Otherwise, the user is definitely at risk, but it's the fault of Foobar.com exposing dangerous functionality without user control, not of the browser vendor. Is that a fair summary of the issue, or are there other security implications of plug-ins being JavaScript-callable that I've overlooked?
Eric's last post seems like a reasonable position to me. Two questions though. 1) Feature question: someone suggested a pref to disable scripting of plugins by untrusted scripts. I know we don't want a lot of extra functionality being added about now, but an additional pref with no UI is a small thing, I think. Should knowledgeable users be able to limit scripting of prefs to signed scripts? One benefit of using a pref is that should this feature ever prove insecure, a script posted to Netcenter or Mozilla.org could disable it by switching the pref. 2) For the engineering folks: The proposed patch allows unrestricted XPConnect access to any object implementing nsIPluginInstance. Is this scheme secure? Could an attacker use this opening to gain expanded XPConnect access? Please think about this one and let me know...I don't know enough about the plugin implementation to answer this question.
mstoltz, I think re: your question (1) that we should haved such a pref, defaulting to "enabled". What braden wants is reasonable. For reasons of backward compatibility, I don't expect netscape.com or even mozilla.org to default untrusted scripting of plugins to "disabled". I leave (2) for later, and for better brains than my currently fried one (been hacking with FSF libbfd for bloatblame...). /be
I'll throw something out re: (2) the security implications to get an answer to this question rolling. My plugin is an xpcom component that implements the nsIPluginInstance interface which can be instantiated either as an <embed> plugin or as a pure XPCOM object. If I've instantiated it as an object in js (not via an embed HTML tag), when I attempt to call its methods, I get an 'access to service denied' - even though it implements the nsIPluginInstance interface. The access fails (when an untrusted page is loaded via http) since the object is not an embedded html element (embedded plugins get XPConnect wrapped at http://lxr.mozilla.org/seamonkey/source/layout/html/content/src/nsHTMLEmbedEleme nt.cpp#319 the first time an attempt is made to invoke one of its methods). I'm not familiar enough with the DOM/etc to know if there are any other components that are 'embedded elements' and could therefore be accessed from an unsigned script if it were to implement the nsIPluginInstance interface.
[nsbeta2+]. Mitch, does the patch work for you?
Whiteboard: [nsbeta2+]
The patch works, but I'm worried about it opening up potential security exploits. I'd like to hear from some plugin/xpcom folks about whether they think this is the right approach.
<URL:http://news.cnet.com/news/0-1005-200-1820959.html?tag=st.ne.1002.tgif.ni> There is much philosophical similarity in the exploit described in this story and the exploit potential created by allowing untrusted scripts to run (trusted) plugin code. *** It should be a basic principle that untrusted code should not be able to interact with trusted code without the *explicit* consent of the user. *** Microsoft's failing in this instance is that they have not honored this principle: they apparently allow an arbitrary (untrusted) Web site to run a trusted script on the local machine. It is no different for Mozilla to allow untrusted script code from a Web site to execute trusted plugin code on the local machine.
Braden, I appreciate and share your interest in achieving a robust security model. However that MS exploit is a separate issue. Here's why: 1) In the referenced MS exploit, a hostile remote web site is able to run local, private JavaScript on my hard disk that I *at no time* have ever authorized to be run by other web sites. 2) In this bug report, we're talking about the fact that native binary plug-ins, as a documented feature that's existed ever since LiveConnect in Navigator 3.0, are callable from any JavaScript code on any web page, if the plug-in implements a LiveConnect Java API. The user implicitly consents to this capability through the action of installing the native binary plug-in. (Yes I'm aware that most users don't understand the technicalities to this depth, but the point is that as always, whenever you install a native binary on your disk, you are completely placing yourself at the mercy of the developer of that binary.) It is the responsibility of the plug-in developer to make sure that the functionality of its Java API, which they know will be callable by any JavaScript on any page anywhere, will not harm the user or violate security or privacy. Netscape has always stated that Java and JavaScript implementations are preferable to native binary ones such as plug-ins because they include a capabilities-based security model, but users and developers clearly want the freedom to use native binary plug-ins (with JavaScript callability) as well. This is not a change to the status quo; this *is* the status quo, and it's crucial that we preserve backward compatibility. Untrusted JavaScript code has been able to call plug-ins Java APIs via LiveConnect since Nav3.0. Let's *please* not complicate and confuse this bug report by turning it into a debate about whether it is or isn't the same or a "philosophically similar" situation to the MS exploit. The issues are fundamentally different. (If you wish to debate that further, please email me directly.) Instead, let's keep this bug report focused on (1) achieving backward compatibility, and (2) making sure that our new architecture doesn't create new security issues that didn't exist in the past.
Eric, I find your closing sentiment, "If you disagree with me, please don't discuss it here," quite offensive. I think the analogy gives insight to the problem here, or I wouldn't have mentioned it. You obviously disagree (as you are of course free to do), but I think your suggestion that this shouldn't be discussed in this venue--just because you and I don't see eye to eye--is not appropriate. 1) Just as the MS exploit allows an arbitrary Web site to run JavaScript in known locations on the local machine, the Netscape plugin exploit allows an arbitary Web site to run arbitrary binary code (a plugin) on the local machine. The fact that one of these happens to be a binary and the other isn't is really irrelevant, since they both have about the same potential to do damage. Now, if you're telling me, "It's okay to do this for plugins because this is documented behavior," then Microsoft is *not* at fault in the aforementioned case as long as this feature is documented. (And I think it is.) Instead, it is Netscape that has committed the Goof. I don't buy into that line of thinking, but *that* is the logical conclusion of the argument that this is a matter of documentation and "accepted" behavior. 2) There are two ways of looking at the status quo: * It is a security hole. * Or, it simply limits the potential functionality of plugins. While you espouse the latter perspective, I would like to see plugins given the flexibility trusted scripting would afford. You're telling me that plugins shouldn't have that flexibility just because they haven't had it before. I don't think that's good enough. If the machinery to do this weren't already in place (and please, someone correct me if my impression that this *is* basically in place is incorrect), I could see the justification for not *adding* it. But since it is in place, it sounds like you are asking for Mozilla to become less flexible (and arguably less secure) to satisfy Netscape's desire for backward compatibility with their legacy product. That is troubling. And even you, Eric, acknowledge that users are likely to be naive to the potential risks associated with plugins. That naivete compromises the integrity of the system--the net effect is a security flaw. There are two ways to fix this. You either either ensure your users are sufficiently educated to properly use the product in its default mode, or you change the default mode. Only one of these options has any hope of being implementable.
Easy, Braden. I didn't say that "because you disagree with me, you shouldn't write here." My point was that a detailed philosophical debate about the definition of security models and whether a given piece of documented longstanding Nav3+ functionality is or is not in some sense the same as a particular reported MS exploit (and again, it's not) is more appropriate to a newsgroup thread or an email exchange than to a particular bug report. (For example, are we going to go through each reported MS IE exploit one at a time in the Description of this bug and compare it? That's the point I'm making.) I suggested email rather than newsgroups as the risk of being quoted out of context by reporters makes any security-related newsgroup postings by a Netscape product manager extremely time consuming to write and review from every angle (an unfortunate reality that product managers, as company spokespeople, have to live with), and I personally am pressed for time right now. But of course, as always, you're free to disregard my own personal interpretation about the best possible use of each forum for different kinds of communication and to write whatever you wish in this report. You are correct that the fact that untrusted scripts can call plug-in APIs clearly limits the kind of functionality that plug-in vendors can safely expose through their APIs. (reformatHardDriveWithoutAConfirmationAlert() being the obvious example of something a plug-in vendor wouldn't want to do.) Plug-in vendors have always been aware of this, worked within that constraint, and produced a large variety of useful plug-ins in spite of it. You're also correct that the Plug-in API and the Mozilla security model *might* be enhanceable to require user-granted permissions for certain operations (although once you switch execution into native binaries, new security model issues arise, so this could be tricky from a practical standpoint or perhaps impossible to guarantee integrity from a theoretical standpoint). You're also correct that it might be possible to enhance the user preferences to provide additional user control. However, both of these appear to be enhancement requests for the security model distinct from this bug, which tracks the need to enable scripting of embeds by unsigned scripts in order to provide backward compatibility. (Please open separate enhancement request bug reports on them if you wish.) FYI on resources, schedules, and enhancement requests: Netscape for its part has committed to provide in Mozilla backward compatibility with existing plug-in content and security no less than what existed for Nav4, and our resources are pretty fully committed doing that, so after 5/16, unfinished enhancement requests will be marked FUTURE due to the new feature cutoff unless perhaps an exception is made or another member of the mozilla community wishes to take them on. But regardless of whether a new enhancement may or may not make the first release, I want to see all good ideas entered and tracked, so by all means please open separate enhancement bug reports on those. Thanks!
One more point: I *do* like the idea of an "Enable scripting of native binaries by untrusted scripts" preference. I *will* be very happy if we can get such a thing (it increases the degree of user control and also provides a useful tempoary workaround if we ever have an unexpected security exploit in this area). But I'm not formally requesting this enhancement from engineering at this late date due to schedule and resources; if someone can get it in, great, but we can FCS without it. I agree with Brendan that if such a preference is created, it should be enabled by default. Users would not thank us if we forced each one to learn about, find, and set that preference manually in order to access existing content.
Fix checked in. We allow XPConnect access from any script to any object implementing nsIPluginInstance, if the preference "security.xpconnect.plugin.unrestricted" is set to true. It is true by default. Marking FIXED.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Changing QA contact to cathy ( czhang@netscape.com ) Add self to cc list
QA Contact: junruh → czhang
confirmed: security.xpconnect.plugin.unrestricted" is set to true by default
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: