User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041306 Minefield/3.0pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041306 Minefield/3.0pre web page is embedding FCKEditor in a separate IFRAME web application is signed (communicates with custom FF extension) fckeditor is wrapped in a simple html which contains several interface function to control the editor when editor is required, IFRAME is created in DOM and loaded with this wrapper.html subsequently, one of the interface functions is called, call looks like this: window.frames['acEditorIFrame'].fckCreateEditor(content, loc); this call throws: Error: Permission denied to get property Window.document Source File: jar:http://s0m3body:8180/autocost/html.jar!/autocost/js/acEditor.js?rel=2007_09_21_08_03 Line: 21 in firefox 3, but works well with firefox 2 Reproducible: Always Steps to Reproduce: 1. go to www.autocost.de 2. log in as mozillabug/mozillabug90505 3. click on 'Params' (top menu bar) 4. click on 'Edit' - in opened 'window' Actual Results: firefox2 opens window (IFRAME) with fckeditor firefox3 throws exception Expected Results: firefox3 opens window with fckeditor i have also tried enabling all sorts of privileges before calling: window.frames['acEditorIFrame'].fckCreateEditor(content, loc); but without success

to make it more clear - wrapper.html and fck editor IS NOT SIGNED -> i.e. it is signed script (and signing works, i can acquire privileges, etc ...) trying to call javascript function from an iframe which is not signed -> domain is the same but the protocol not (jar: vs http:) - however, it has been working fine with firefox2

I can confirm seeing this as well. We have a web application that's been working for quite some time that uses signed JavaScript in an IFRAME. The detection and handling of that signed JavaScript works with versions of Firefox through 2.0.0.14. In doing compatibility testing with Firefox 3.0 RC 1, we have found that this signed JavaScript is NOT working as reported by this bug.

Yes, same here with FF2 its fine, with FF3 I get: Error: Permission denied to get property Window.fckCreateEditor Source File: jar:https://www.automarker.com/autocost/html.jar!/autocost/js/acEditor.js?rel=2008_04_12_19_43 Line: 1. This needs fixing ASAP

This is also affecting Lotus Domino.

bz, any thoughts here?

This change was made on purpose, in bug 418996. Before that, nsIPrincipal::Equals was asymmetric if one of the principals was signed and one wasn't, allowing violations of the same-origin policy. See also bug 434544, which is about this exact issue, as far as I can tell (so perhaps this bug should be marked duplicate). Basically, any time a signed jar was being used in a way that triggers this bug, the signed jar was exploitable in Gecko 1.8....

Perhaps we needed more outreach on this change... :( I think we underestimated the number of sites relying on the (obviously insecure!) asymmetric access....

Do you mean that signed code calling unsigned code for some well defined specific tasks, separated for the 'main' part of the web application running from a signed JAR is insecure ? Or is it something I haven't understood properly ?

(In reply to comment #8) > Do you mean that signed code calling unsigned code for some well defined > specific tasks, separated for the 'main' part of the web application running > from a signed JAR is insecure ? Yes, that sounds insecure. Do you have an example signed JAR that does this? We might be able to demonstrate the issue to you.

jar:https://www.automarker.com/autocost/html.jar!/autocost/cop.html You can log in as mozillabug/mozillabug90505 and reproduce it: 1. go to jar:https://www.automarker.com/autocost/html.jar!/autocost/cop.html 2. log in as mozillabug/mozillabug90505 3. click on 'Params' (top menu bar) 4. click on 'Edit' - in opened 'window' Actual Results: Firefox2 opens window (IFRAME) with fckeditor Firefox3 throws exception Expected Results: Firefox3 opens window with fckeditor ---- It creates an IFRAME using code like this: acEditorIFrameRef=document.createElement('iframe'); acEditorIFrameRef.name='acEditorIFrame'; acEditorIFrameRef.id='acEditorIFrame'; ..... acEditorIFrameRef.src=locationPrefix+'fckeditor/wrapper.html'; ... document.body.appendChild(acEditorIFrameRef); Wrapper.html contains fck editor plus couple of functions to set and retrieve document which fckeditor is editing. So - subsequently I try to pass content (which I have in 'main' application in signed jar) to the fckeditor via something like this: window.frames['acEditorIFrame'].fckEditorSetHTML(content); And this part now fails with firefox 3. Fckeditor (or wrapper.html to be more precise) should have no option to modify anything anything in the main part, 'Save' button is part of the signed application, so once the editing should be done, what I do is: var xhtml=window.frames['acEditorIFrame'].fckEditorGetXHTML(); to retrieve the edited document out of the fckeditor, followed by hiding the editor with a code like this: acEditorIFrameRef.style.display='none'; I.e. -> fckeditor IFrame does not need any access to the main application, only main application needs to control fckeditor IFrame (so secure part controlling insecure part). Surely, any data passed back from insecure part should be validated and the application should expect that malicious content can be returned from the insecure part, but in my opinion, this should be solved via proper design of the web application, not by complete isolation between secure and insecure parts of the code. Of course, the problem may be much deeper then I can see at the moment, that's why I am trying to understand it, and find out if there are possible workarounds besides signing the whole application.

We only use a small amount of signed JavaScript. It is only used to wrap access to the clipboard for our web application. Only the code that actually tries to access the clipboard is signed. Our HTML is constructed like this: <HTML> <HEAD> <SCRIPT> ... window.SignedCB.getCBData(); ... </SCRIPT> </HEAD> ... <BODY> ... <DIV> <IFRAME id="SignedCB" name="SignedCB" src="jar:http://xx.xx.xx.xx/SignedCBAccess.jar!/SignedCBAccess.html"> </IFRAME> </DIV> </BODY> </HTML> where the window.SignedCB.getCBData() function is contained in JavaScript contained in SignedCBAccess.html contained in SignedCBAccess.jar which is signed. With Firefox 3, we get a JavaScript exception stating "Error: Permission denied to get property Window.getCBData". With Firefox 2, this works with the user possibly being prompted to accept the certificate used to sign the jar. Will this be fixed in Firefox 3 at some point or is what we're trying to do deemed to be a security violation? Is there any way we can change the structure of this to allow access to the signed JavaScript from the unsigned portion of the page? Thanks.

Dennis, what you're doing is almost certainly exploitable in Firefox 2, as I said above... And worse yet, the few cases that are not exploitable can't be told apart from the ones that are (well, without solving the halting problem or completely redesigning the entire web security architecture to error out as late as possible instead of as early as possible)

Is there a bug somewhere (private or not) that explains how it is exploitable? You just keep saying it is, I thing people need an explanation why. To them it just looks like something was broke.

Uh... like the bug this is considered a regression from and which is in the "blocks" field here? Yes, yes there is.

But even simpler, the existing setup allowed the unprivileged page to script the signed page (as per comment 11). Which means you can inject script into the signed page, and that script will then get the permissions of the jar. Which is bad, for obvious reasons.

I am unable to read the "Depends on" and "Blocks" bugs. Selecting either of them gives me a "You are not authorized to access bug" error. Can these be opened to a wider audience for access?

Not yet, since Firefox 2, for example, still has the relevant vulnerabilities, as do other Gecko-based products...

Security issue of #11 (calling signed script by unsigned script) is quite clear. However, why do the same approach/policy apply to the opposite way -> signed script calling unsigned script ? These are two complete different situations, latter (if handled this way) bringing a sort of 'viral' effect to any signed script, and can cause either not using signing at all, or signing 3rd party code 'just because it has to be signed'. Don't you think ?

> However, why do the same approach/policy apply to the opposite way -> > signed script calling unsigned script ? Because in this situation the unsigned script can actually cause arbitrary code of its choice to be executed with the privileges of the signed script. This is also why chrome code never accesses content objects directly, using XPCNativeWrapper instead.

Oh, and the other thing to keep in mind is that same-origin policy is symmetric. At some point we may have an asymmetric security policy, maybe, but we're not there yet, and doing it will take a lot more legwork in various parts of the code... As things stand, any time there is an asymmetry in a same-origin check, either one direction is too strict, or the other direction is allowing an exploit.

Is there no possibility how a signed script could call unsigned with dropping privileges of the signed script ? Just call it, later on possibly fetch up some result, etc ...

Ok, if it is symmetric, then there isn't ...

You can use the postMessage API (new in Gecko 1.9) to communicate safely between windows which are not same-origin.

Thanks for the tip, Boris ! So basically, the possibility of free communication between frames (different origin) has been reduced to postMessage -> even if I can see the motives, I find it pity that there isn't a more sophisticated way of exposing some API methods or anything which would make the communication easier to handle -> as at the moment passing parameters means lots of parsing (or even worse, using eval for 'simplicity' which introduces security issues again ...). However, as the 'postMessage' is a workaround and I have been able to fix the reported problem in my web application, from my point of view this bug can be considered closed ... (unless someone thinks it still needs to be resolved differently).

As of Firefox 2.0.0.15 you're now running into this problem on Firefox 2 -- and there's no postMessage feature to use as a workaround. Ultimately if you can get your users to trust you to grant extended permissions then you should be able to get them to install a helper add-on, and you should be able to do what you need safely from chrome. I apologize we couldn't fix the security hole and preserve this feature. http://www.mozilla.org/security/announce/2008/mfsa2008-23.html

Could you please explain, what do you exactly mean by 'granting extended permissions' ? Is there a Firefox setting which 'disables' this security feature/change for a specific site ?

Documentation updated (finally): https://developer.mozilla.org/en/Updating_web_applications_for_Firefox_3#Using_remote_JARs_in_frames