434544 - Cross Scripting between signed and unsigned Web Pages broke

Status: RESOLVED WONTFIX

(Firefox :: Security, defect)

Description

[Silvio Huckel]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 1.1.4322; .NET CLR 3.0.04506.30)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0

Hi,

We have developed an XPCOM Add-On which is being used by many of our customers for some while now. 
This Add-On is controlled by using JavaScript in a signed HTML file and the objects of this same HTML file are driven themselves by some JavaScript of an unsigned dynamically-generated web page (ASPX). We chose this solution because it is NOT possible for us to sign the dynamically-generated web pages; this would be much too complex, as we use a lot of cross scripting. Of course, we do NOT make use of cross site scripting (XSS) which we know is forbidden.
This works perfectly well in Firefox 2, but we recently discovered that this seems to be forbidden in Firefox 3. Even the usage of “unsigned” objects from “signed” JavaScript seems to be prohibited.
We understand that this might involve a security issue, but this was for us a major feature which is now broken.
How can we control an Add-On using dynamically-generated web pages? Is there another solution?

Thanks for your help.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Can you find a regression range, using binary search through builds from ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ ?

Comment 2

[Fred Mandrea]

Attachment: A very simple testcase to show the problem

This sample contains a html and a jar (signed) file containing a second html file.

Each file tries to read a string in the other file.

Comment 3

[Fred Mandrea]

Hi Gavin,

The changes seem to appear between 18-03-2008 and 19-03-2008 nightly builds (trunk directory, milestone 3.0b5pre).

I've just added an attachment which contains a very simple test case, so you can see what happens.

You can notice that the version compiled on the 18th of march enables both signed and unsigned script to have access to each other's objects.
With the version compiled on 03-19, none of them is able to do it anymore.

I emphathize on the fact that this is a huge problem for us since at least one of our files must be dynamic and that we cannot sign it automatically.

Comment 4

[:Gavin Sharp [email: [e-mail]]]

Thanks Fred. I assume you tested the builds at:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008/03/2008-03-18-06-trunk/
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008/03/2008-03-19-05-trunk/
specifically?

That gives the following range:
http://bonsai.mozilla.org/cvsquery.cgi?branch=HEAD&date=explicit&mindate=2008-03-18+04%3A00&maxdate=2008-03-19+06%3A00

which means most likely caused by the fix for bug 418996, which I should have realized before now. You were essentially relying on a security hole, and we've now fixed it. I don't think we're going to revert that change, so I'm not sure there's much that can be done on our side.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Yeah, the issue is that your setup as-is can be exploited by anyone who bothers to download your jar file and put it up on their own website.  They can then make the user think that you're asking for expanded privileges while in reality they're the ones doing that, and thus gain access to things the user is willing to give you access to.

Would it be feasible for you to move your signed script page into chrome (as a part of your extension) instead?  Chrome would be able to access the unsigned page.

Alternately, the signed page could request UniversalXPConnect privileges, which ought to enable it to access the unsigned page.  This method might well stop working in Firefox 4, though, so the "move it into chrome" thing is more future-proof.

Comment 6

[Daniel Veditz [:dveditz]]

It's unfortunate that we have to break you this way, but we are not going to revert the security change. We're even implementing it in the next update of Firefox 2.0.0.x which might affect you even more :-(

Limiting permissions with signed code turns out to eventually expand to all permissions, it is ultimately simpler to have your users download and install an addon to work with only your site and deal with the security implications there.

Comment 7

[Fred Mandrea]

At the moment, correct me if I'm wrong, but chrome solution would only enable us to access unsigned object from the signed page. Alas, nothing seems to be possible in the opposite way (i.e. to enable unsigned page to use signed page). Unfortunately, I'm afraid we do need both ways to work correctly with our code.

Security is definitely a priority for web browsers, so we understand the need to prevent incorrect use of components. Nevertheless, we do think Firefox should first provide a solution to access objects in a signed page from a dynamic page, without needing to sign the latter each time.
For instance, such problem could be avoided if we could grant privileges for pages coming for a given domain name, rather than a page which needs to be signed each time the generated code changes.

I don't like to write that, but if you implement that security change in the next update of firefox 2, our only option atm will be to ask our firefox customers to move to our corresponding IE/ActiveX solution... :-(

Comment 8

[Boris Zbarsky [:bzbarsky]]

> For instance, such problem could be avoided if we could grant privileges for
> pages coming for a given domain name

You can, with an extension.  The extension could just set the relevant preferences.

Something like:

  user_pref("capability.principal.codebase.myUniqueNameHere.granted",
            "UniversalXPConnect");
  user_pref("capability.principal.codepase.myUniqueNameHere.id",
            "https://myhost.mydomain.tld");
  user_pref("capability.principal.codebase.myUniqueNameHere.subjectName",
            "");

Alternately, an extension could listen for events dispatched by untrusted code and do whatever it wants to with them; that allows the untrusted code to communicate with trusted code at the extension's discretion.

Comment 9

[Daniel Veditz [:dveditz]]

(In reply to comment #7)
> our corresponding IE/ActiveX solution... :-(

not that it will help you convert your app in the short run, but signed javascript was not ever the Firefox equivalent of ActiveX. A downloaded plugin or extension would be more equivalent in power and flexibility.

In Firefox 3 you might be able to use the new postMessage() feature to communicate information (but not raw DOM access) between signed and unsigned frames. Don't know if that helps any with what you're trying to do or not.

Although early on you say you do have an AddOn -- I'm not sure what you're trying to communicate between them, but you surely can. You could implement a global object as a js component, like window.sidebar. Or if you know only specific domains need access you could dynamically add the object or methods to pages from a list of domains (e.g. Greasemonkey does something like this when it runs userscripts only for specific domains).

Hard to say what approach is best without knowing more detail about what you're trying to do. You could get more help in our IRC channels (try irc://irc.mozilla.org/extdev ) or the newsgroup news://news.mozilla.org/mozilla.dev.extensions

Unfortunately Firefox 2.0.0.15 will have the security fix that breaks you --
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2.0.0.15-candidates/ -- and will be released next week: http://wiki.mozilla.org/Releases

Comment 10

[Fred Mandrea]

Thanks to everyone for your help. We finally used the event-based solution, as Boris suggested, and it seems to work fine now.

Regards,
Fred

PS: Daniel, I did not mean to make a comparison between ActiveX and signed javascript. In our case, signed javascript is mostly used to drive our XPCom component (which does basically the same as our ActiveX component for MSIE).

Comment 11

[Taka]

I did find a sort of fix too for a very similar problem. It makes me feel very doubtful in how much this "security hole" has been fixed. In stead of asking a user for permission once, now it requires two or three times asking for permission. That does not really make things more secure (it is only an annoyance to do so).

I looked briefly to the extension option, but that seems a lot of overkill for just asking permission from users for some functionality. Look at how much it takes for a simple "Hello World" world extension: http://kb.mozillazine.org/Getting_started_with_extension_development

It would be nice to have the option to create an extension with the code that needs permission from the user and not much more. Maybe that is already possible, but the "getting started" guide should be rewritten then. My time is precious.