1169385 - Leaking Hello conversation links through referrer header to HTTPS third party sites

Status: RESOLVED FIXED

(Hello (Loop) :: Client, defect)

Description

[Muhammad Shahmeer]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36 OPR/27.0.1689.76

Steps to reproduce:

Hey there team
This is Shahmeer and i am reporting a very critical issue in firefox hello application, The issue is that the Hello conversation links can be leaked to third party sites or over HTTP, this might be unknowingly by victims themselves

If a link is posted in the hello conversation, When the user clicks the link he is redirected to that site but in the process the hello conversation link which is supposed to be private is also leaked in the Referer. If the website is HTTP the link is over cleartext accordingly.


Actual results:

Using these links the third party sites that might be malicious can join the sensitive conversations between users, this leaking information to those sites


Expected results:

To prevent i suppose you apply an intermediate page so that firefox hello links are not leaked

Comment 1

[:Gijs (he/him)]

Seems like we could just use rel="noreferrer" and/or <meta name="referrer" content="origin"> or similar.

By default we wouldn't send a referrer to a HTTP site because the Hello code runs on https.

Comment 2

[:Gijs (he/him)]

(In reply to :Gijs Kruitbosch from comment #1)
> Seems like we could just use rel="noreferrer" and/or <meta name="referrer"
> content="origin"> or similar.

FWIW, I'm assuming all the browsers that the hello client page works on support these... which may not be true, I suppose? Chrome certainly does, and last I checked IE didn't support webrtc... but I'm less sure about Safari.

Comment 3

[Daniel Veditz [:dveditz]]

(In reply to :Gijs Kruitbosch from comment #1)
> Seems like we could just use rel="noreferrer" and/or <meta name="referrer"
> content="origin"> or similar.

rel="noreferrer" would be better because it also nukes window.opener and prevents a malicious window from nuking your conversation window. Then again, if it's a malicious page why is the conversation originator passing along that link?

Damage seems relatively minor, at least for now: while the two people are conversing a third person with the link cannot join the conversation anyway. If there's anything sensitive in the "context" that's sent along they won't get that either because it's referenced from the fragment and the fragment isn't sent along with the referrer. It does mean someone could jump into your room later and wait for you, or prevent other people from reaching you in that conversation (which would be a problem if you can't reach them to give them a new link).

As Gijs said this can't be leaked over insecure http, it will only leak to the link you include in the context. Is there another way to share links that I didn't find?

Comment 4

[Muhammad Shahmeer]

I think you are overlooking the fact, Anyone can join the conversation in Hello if he has the link, The damage here is not minor according to me. But the party if malicious, Like if image hosting sites that have images hosted on HTTP but the the link on HTTPS, that would circumvent the HTTPS leakage protection. This is in no way low severity

Comment 5

[Mark Banner (:standard8)]

To clarify a couple of things:

1) The only way users can insert links at the moment is via a new feature "context in conversations". Adding context is new in FF 40 and not available generally yet. The servers and link-clicker web pages support it, but that would require sending a room link to someone.

2) The other links from the hello.firefox.com pages are two mozilla-owned, https sites. Hence I think our standard policies and trust levels are reasonable to apply there.

3) This doesn't affect the small conversation window within Firefox, links are routed though different mechanisms to avoid window.opener issues.

4) This does affect the link clicker page when context is enabled. Context will only work on browsers that support web crypto. It'll also only be displayed if the browser is supported for Hello.

Given 4, I think we're reasonably ok to use rel="noreferrer" - Chrome implemented it in about 2009, Firefox implemented it in 33, although not fully until 37 (Web Crypto was implemented in FF 34, so the remaining range would be 34 - 37).

Using the <meta name="referrer" content="origin"> might be enough to work around it on those older versions of FF, though I'll take a look at that next week.

Comment 6

[Muhammad Shahmeer]

Okay, Do what you have to do, But tell me does this qualify for a bounty?

Comment 7

[Mark Banner (:standard8)]

Dan, further to comment 5, I found out today that FF implemented the meta referrer tag in 36. Therefore, I think we can use the meta tag and the rel="noreferrer" in combination.

This would fix the issue for Chrome/Opera users, and Firefox users would be covered from 36 onwards. Users of FF 34/35 could be affected in a limited set of cases (right-click & open link), but since they are already three versions old, I don't think its worth doing something more extensive.

Users of other browsers, won't see the context links, and hence the only links available will be to sites we trust/own and that are https (i.e. FF download, www.mozilla.org).

So unless there's something I'm missing, I think we should move forward with adding the meta and the rel attributes.

Comment 8

[Daniel Veditz [:dveditz]]

(In reply to Mark Banner (:standard8) from comment #7)
> So unless there's something I'm missing, I think we should move forward with
> adding the meta and the rel attributes.

Sounds great to me.

Comment 9

[Daniel Veditz [:dveditz]]

(In reply to Muhammad Shahmeer from comment #6)
> Okay, Do what you have to do, But tell me does this qualify for a bounty?

The developers don't know, please send your bounty-related communication to security at mozilla.org

Comment 10

[Mark Banner (:standard8)]

Attachment: Add referrer controls for Loop standalone page.

I've had this patch in my tree for a while, just not uploaded it as I was hoping to get the automated checks done. However since we're coming up to a release, we should land this now, and I'll deal with the automation later.

Comment 11

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 8624378 [details] [diff] [review]
Add referrer controls for Loop standalone page.

Review of attachment 8624378 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me; r=dmose

Comment 12

[Mark Banner (:standard8)]

Landed in the tree, this will be deployed in a few days.

https://hg.mozilla.org/integration/fx-team/rev/8e4b2fe4f3fa

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/8e4b2fe4f3fa

Comment 14

[Daniel Veditz [:dveditz]]

Does not qualify for a bounty unless there's a PoC demonstration of how you're interjecting yourself in someone else's conversations.

Comment 15

[Mark Banner (:standard8)]

The patch here was deployed a couple of hours ago along with some other updates.

Comment 16

[Muhammad Shahmeer]

Here is a scenario
Victim posts some link in the chat before giving it to someone
Victim himself visits the link and the link gets leaked through referer
Now the third party having the link can misuse it