bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

BroadcastChannel API bypasses Browser API sandbox on B2G

RESOLVED FIXED in Firefox 40, Firefox OS master



3 years ago
2 years ago


(Reporter: Muneaki Nishimura, Assigned: baku)


({privacy, sec-low})

37 Branch
Windows 8
privacy, sec-low
Bug Flags:
sec-bounty -

Firefox Tracking Flags

(firefox38 wontfix, firefox39 wontfix, firefox40 fixed, firefox-esr31 unaffected, firefox-esr38 wontfix, b2g-v2.2 unaffected, b2g-master fixed)


(Whiteboard: [post-critsmash-triage][adv-main40-][b2g-adv-main2.5?])


(3 attachments)

514 bytes, application/x-zip-compressed
565 bytes, application/x-zip-compressed
16.75 KB, patch
: review+
Details | Diff | Splinter Review


3 years ago
User Agent: Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2342.2 Safari/537.36

Steps to reproduce:

1. Install attached packaged app 'victim.zip' and 'victim2.zip' on Firefox OS simulator 3.0.
2. Start Browser app and open 'http://csrf.jp/bc/receiver.html'.
3. Start victim app. The app loads message receiver page from http://csrf.jp on it's iframe.
4. Start the victim2 app. The app loads message sender page from http://csrf.jp on it's iframe[mozbrowser].
5. Push 'Send Message' button in the sender page of victim2.app, and then, BroadcastChannel message is sent.
6. Open the victim app again. Then, you can see the received message from victim2 app on the alert popup.
7. Open the Browser app agaon. Then, you can see the received message from victim2 app on the alert popup.

Actual results:

This message sent from <iframe mozbrowser> is delivered to other apps.

Expected results:

The message sent from Browser app should not be delivered to other apps outside of the Browser API sandbox in an app.
Note that this bug was origiinally reported in [Issue 3] in Bug 1147778.

Comment 1

3 years ago
Created attachment 8583985 [details]

Comment 2

3 years ago
Created attachment 8583987 [details]
Flags: sec-bounty?
Not clear to me that broadcasts to a web page aren't supposed to apply to web pages loaded by different apps. It's still web pages in browsers. I guess this could be used to synchronize app cookie jars.
Component: Untriaged → DOM
Product: Firefox → Core


3 years ago
Assignee: nobody → amarchesini

Comment 4

3 years ago
Created attachment 8586836 [details] [diff] [review]
Attachment #8586836 - Flags: review?(ehsan)


3 years ago
Duplicate of this bug: 1148031

Comment 6

3 years ago
Comment on attachment 8586836 [details] [diff] [review]

Review of attachment 8586836 [details] [diff] [review]:

::: dom/broadcastchannel/tests/test_broadcastchannel_mozbrowser.html
@@ +83,5 @@
> +       { "type": "webapps-manage", "allow": 1, "context": document }], nextStep);
> +  },
> +
> +  function() {
> +    SpecialPowers.setBoolPref("network.disable.ipc.security", true);

Why not use pushPrefEnv for this too?
Attachment #8586836 - Flags: review?(ehsan) → review+

Comment 8

3 years ago
dveditz can I land this patch immediately? I don't see a valid reason to have it sec-critical actually.
Flags: needinfo?(dveditz)
Yes, we can land this now.
Ever confirmed: true
Flags: needinfo?(dveditz)
Keywords: privacy, sec-low
Last Resolved: 3 years ago
status-firefox40: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
Minusing for bounty because it is a sec-low rated issue.
Flags: sec-bounty? → sec-bounty-
status-firefox-esr31: --- → unaffected
It looks like the patch here makes us use the manifestURL *rather* *than* the origin as part of the key when broadcasting messages. The other part of the key is of course the broadcast-channel-name.

Is this correct?

If so, doesn't that mean that all webpages, from all domains, in an app that use the same broadcast-channel-name? I.e. facebook.com and google.com would share broadcast channels?

If that's what we do, then that's not desired behavior.

What we should do is we should use the appid+browserflag+origin as key, plus the broadcast-channel-name. An easy way to do that is to use the nsIPrincipal.jarPrefix+origin as key.

Comment 16

3 years ago
Jonas, I'm going to file a new bug for this. Thanks for find this issue!
Blocks: 1161507
Only a sec-low, but something we might want to consider for v2.2 still?
status-b2g-v2.2: --- → ?
status-b2g-master: --- → fixed
Flags: needinfo?(ptheriault)
Yes that sounds like a good idea, and assume that means including 1161507 too. (I don't have +'ing rights...)
Flags: needinfo?(ptheriault)
Andrea, please request b2g37 approval on this and bug 1161507 :)
status-b2g-v2.2: ? → affected
status-firefox38: --- → wontfix
status-firefox39: --- → wontfix
Flags: needinfo?(amarchesini)

Comment 20

3 years ago
Comment on attachment 8586836 [details] [diff] [review]

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 966439 / BroadcastChannel API
User impact if declined: in B2G, broadcastChannel can send messages to the wrong origin.
Testing completed: yes, a mochitest is included
Risk to taking this patch (and alternatives if risky): none
String or UUID changes made by this patch: none
Flags: needinfo?(amarchesini)
Attachment #8586836 - Flags: approval-mozilla-b2g37?
Comment on attachment 8586836 [details] [diff] [review]

Whoops, BroadcastChannel landed on Gecko 38, so v2.2 is unaffected. Sorry for wasting your time, Andrea :(
Attachment #8586836 - Flags: approval-mozilla-b2g37?
status-b2g-v2.2: affected → unaffected
Whiteboard: [post-critsmash-triage]
status-firefox-esr38: --- → wontfix
Whiteboard: [post-critsmash-triage] → [post-critsmash-triage][adv-main40-]
Whiteboard: [post-critsmash-triage][adv-main40-] → [post-critsmash-triage][adv-main40-][b2g-adv-main2.5?]


3 years ago
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.