Can you find a regression range, using binary search through builds from ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ ?
Created attachment 321937 [details] 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.
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.
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.
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.
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.
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... :-(
> 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.
10 years ago
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.