Closed Bug 1148033 Opened 5 years ago Closed 5 years ago

BroadcastChannel API bypasses Browser API sandbox on B2G

Categories

(Core :: DOM: Core & HTML, defect)

37 Branch
x86
Windows 8
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla40
Tracking Status
firefox38 --- wontfix
firefox39 --- wontfix
firefox40 --- fixed
firefox-esr31 --- unaffected
firefox-esr38 --- wontfix
b2g-v2.2 --- unaffected
b2g-master --- fixed

People

(Reporter: sdna.muneaki.nishimura, Assigned: baku)

References

Details

(Keywords: privacy, sec-low, Whiteboard: [post-critsmash-triage][adv-main40-][b2g-adv-main2.5?])

Attachments

(3 files)

514 bytes, application/x-zip-compressed
Details
565 bytes, application/x-zip-compressed
Details
16.75 KB, patch
ehsan
: review+
Details | Diff | Splinter Review
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.
Attached file victim.zip
Attached file victim2.zip
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
Assignee: nobody → amarchesini
Attached patch bc2.patchSplinter Review
Attachment #8586836 - Flags: review?(ehsan)
Duplicate of this bug: 1148031
Comment on attachment 8586836 [details] [diff] [review]
bc2.patch

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+
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(dveditz)
Keywords: privacy, sec-low
https://hg.mozilla.org/mozilla-central/rev/29bf67773de8
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
Minusing for bounty because it is a sec-low rated issue.
Flags: sec-bounty? → sec-bounty-
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.
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: --- → ?
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 :)
Flags: needinfo?(amarchesini)
Comment on attachment 8586836 [details] [diff] [review]
bc2.patch

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]
bc2.patch

Whoops, BroadcastChannel landed on Gecko 38, so v2.2 is unaffected. Sorry for wasting your time, Andrea :(
Attachment #8586836 - Flags: approval-mozilla-b2g37?
Whiteboard: [post-critsmash-triage]
Whiteboard: [post-critsmash-triage] → [post-critsmash-triage][adv-main40-]
Whiteboard: [post-critsmash-triage][adv-main40-] → [post-critsmash-triage][adv-main40-][b2g-adv-main2.5?]
Group: core-security → core-security-release
Group: core-security-release
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.