1177795 - Access to postMessage denied when used by unprivileged frame inside chrome:// tab

Status: RESOLVED WONTFIX

(Core :: XPConnect, defect)

Description

[Thomas Greiner]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.130 Safari/537.36

Steps to reproduce:

1. Install Adblock Plus from https://adblockplus.org/ (no need to reinstall)
2. Open chrome://adblockplus/content/ui/firstRun.html
3. Click on one of the social media icons in the blue area


Actual results:

- Overlay appears and shortly after disappears again
- JavaScript console contains the error message `Error: Permission denied to access property "postMessage"` (for share.adblockplus.org, platform.twitter.com and apis.google.com)


Expected results:

- Overlay appears and iFrame is being shown containing https://share.adblockplus.org
- No error regarding "postMessage"

Comment 1

[Thomas Greiner]

We have discovered an issue with the Adblock Plus first-run page which is an HTML page that runs in its own tab and inserts an iFrame. Inside that frame https://share.adblockplus.org tries to post a message to the first-run page using `window.parent.postMessage`.
This broke, however, with Firefox 38 causing the following error message to appear in the JavaScript console: `Error: Permission denied to access property "postMessage"`. I was able to narrow this regression down to https://hg.mozilla.org/integration/mozilla-inbound/rev/2870f06405d0

Note that even when using WebChannel.jsm to communicate between top frame and iFrame, the third-party scripts running inside the iFrame are still being denied access to the frames they created within that iFrame.

For reference, this issue was originally reported at https://issues.adblockplus.org/ticket/2710

Comment 2

[Wladimir Palant]

@bholley: I cannot access bug 1126911, this one should be blocking it. I strongly suspect that making window.postMessage() inaccessible was an unintended side-effect of your change there, please confirm. As things are now, it seems that an unprivileged frame inside a privileged frame has no good way of communicating with its parent. WebChannel API would be an option but from what I can tell it will only work in the desktop Firefox (not Fennec or SeaMonkey for example).

Comment 3

[Wladimir Palant]

Actually, this isn't limited to the 38 branch - reproducible in the nightly as well (tested in 41.0a1 2015-06-29 on OS X). It did start with Firefox 38 however.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> I strongly suspect that making window.postMessage() inaccessible was an unintended
> side-effect

Not entirely.  It was a secondary effect in the sense that it's not immediately fixing a known bug, but very much intended, because it would be quite easy for serious problems to arise from untrusted content posting messages to chrome code that does not expect them to come from untrusted content.  We really don't want to allow that.

> it seems that an unprivileged frame inside a privileged frame has no good way of
> communicating with its parent.

You can fire an event on yourself and the parent can register an event listener?  This has the benefit of making the whole setup opt-in...

Comment 5

[Thomas Greiner]

(In reply to Boris Zbarsky [:bz] from comment #4)
> You can fire an event on yourself and the parent can register an event
> listener?  This has the benefit of making the whole setup opt-in...

As noted in Comment 1, this is unfortunately not a complete solution for us since the same issue occurs within that iFrame for third-party scripts we have no control over.

Comment 6

[Bobby Holley (:bholley)]

(In reply to thomas from comment #5)
> (In reply to Boris Zbarsky [:bz] from comment #4)
> > You can fire an event on yourself and the parent can register an event
> > listener?  This has the benefit of making the whole setup opt-in...
> 
> As noted in Comment 1, this is unfortunately not a complete solution for us
> since the same issue occurs within that iFrame for third-party scripts we
> have no control over.

I don't understand - what does window.postMessage buy you in this case that event dispatch does not?

Comment 7

[Wladimir Palant]

My impression is that these scripts are simply using top.postMessage() to see whether they will get a response - they don't expect it to throw. But I think that's something we can solve.

Comment 8

[Wladimir Palant]

This change should be documented IMHO. We did study both https://developer.mozilla.org/en-US/Firefox/Releases/38 and https://www.mozilla.org/en-US/security/known-vulnerabilities/firefox/#firefox38 - no indications that this change was intended.

Comment 10

[Mike Kaply [:mkaply]]

This means that twitter widgets don't work in nested chrome iframes and browsers. Kind of unfortunate. See bug 1185985.

Comment 11

[Wladimir Palant]

Mike, we "solved" the issue with this hack: https://hg.adblockplus.org/adblockplusui/file/tip/common.js#l67. We mark the frame as running an app which makes Gecko establish a security boundary there. For the page inside the frame everything looks like it is the top frame, good enough to make Twitter widgets work.