Closed Bug 428995 Opened 16 years ago Closed 16 years ago

signed script gets Permission denied when calling javascript from IFRAME (unsigned) - works with older firefox2

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: martin.hajduch, Unassigned)

References

Details

(Keywords: dev-doc-complete, regression) 

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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
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....
Blocks: 418996
Depends on: 434544
Perhaps we needed more outreach on this change... :(  I think we underestimated the number of sites relying on the (obviously insecure!) asymmetric access....
Keywords: dev-doc-needed
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
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
Summary: signed script gets Permission denied when calling javascript from IFRAME (unsigned) - works with firefox2 → signed script gets Permission denied when calling javascript from IFRAME (unsigned) - works with older firefox2
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 ?
You need to log in before you can comment on or make changes to this bug.