Closed Bug 1063730 Opened 5 years ago Closed 5 years ago

Screensharing (windows, apps) should only be allowed on https: origin sites

Categories

(Core :: WebRTC, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla35
Tracking Status
firefox33 --- fixed
firefox34 --- fixed
firefox35 --- fixed

People

(Reporter: jesup, Assigned: ekr)

References

()

Details

Attachments

(1 file)

As part of our (and the IETF's/W3C's) continuing push to put new web services on secure connections always, and to avoid a class of hijack/MITM/landing-page hijack attacks, we should limit screensharing not just to sites in the whitelist, but sites that are also loaded over https (like the way we restrict "Always allow" for camera/mic to https sites.)

Per bug 1049583, sites with landing pages that aren't https/HSTS are prone to DNS poisoning/hijacking/AP-based MITM/etc.  (and the sites proposed aren't HSTS/etc, at least not the landing pages for those domains, per gcp)

We would want this in 33 probably.
Here's an example of one that matches the whitelist:

https://ciscosales.webex.com/

It has a cert verified by VeriSign so it should pass this test.  I would be interested to know if it does not.
(In reply to Ethan Hugg [:ehugg] from comment #1)
> Here's an example of one that matches the whitelist:
> 
> https://ciscosales.webex.com/
> 
> It has a cert verified by VeriSign so it should pass this test.  I would be
> interested to know if it does not.

Does it support HSTS?  Otherwise, someone entering http://ciscosales.webex.com can get redirected before they get to the Cisco HTTPS URL.
For anything that is operating off the whitelist, this is definitely worthwhile.  We should only permit access to the whitelist off a strongly authenticated origin.  But that's more about protecting the integrity of the persistent permission grant.

I'm not sure that we have a general policy basis to restrict services to secure origins though.  Discussion about WebCrypto indicates that there is some resistance to following Chrome's principled position on this.

I don't think that we have an HSTS issue here given the nature of the feature.  Hijacking the http:// version of the origin isn't going to provide any advantage to an attacker if we isolate the persistent permission to the authenticated origin.
(In reply to Randell Jesup [:jesup] from comment #2)
> (In reply to Ethan Hugg [:ehugg] from comment #1)
> > Here's an example of one that matches the whitelist:
> > 
> > https://ciscosales.webex.com/
> > 
> > It has a cert verified by VeriSign so it should pass this test.  I would be
> > interested to know if it does not.
> 
> Does it support HSTS?  Otherwise, someone entering
> http://ciscosales.webex.com can get redirected before they get to the Cisco
> HTTPS URL.

OK, I checked and it does not give a "Strict-Transport-Security" value in the response header.  We could probably fix that if required.
(In reply to Ethan Hugg [:ehugg] from comment #4)
> OK, I checked and it does not give a "Strict-Transport-Security" value in
> the response header.  We could probably fix that if required.

It's not required for this, but you might like to consider it for other reasons.
(In reply to Martin Thomson [:mt] from comment #3)

> I'm not sure that we have a general policy basis to restrict services to
> secure origins though.

I want to second this. While I believe we should strongly push for the *default sites we ship* to have proper HSTS/HTTPS safeguards, and thus set the good example and not undermine our pre-set whitelist, this is something quite different from outright blocking the feature to anyone without an HTTPS cert.

>I don't think that we have an HSTS issue here given the nature of the feature.  Hijacking the http:// 
>version of the origin isn't going to provide any advantage to an attacker if we isolate the 
>persistent permission to the authenticated origin.

It circumvents the whitelist. If you don't see a problem with that, then why have the whitelist in the first place?
(In reply to Gian-Carlo Pascutto [:gcp] from comment #6)
> >I don't think that we have an HSTS issue here given the nature of the feature.  Hijacking the http:// 
> >version of the origin isn't going to provide any advantage to an attacker if we isolate the 
> >persistent permission to the authenticated origin.
> 
> It circumvents the whitelist. If you don't see a problem with that, then why
> have the whitelist in the first place?

It doesn't circumvent the whitelist if the whitelist is only checked for https:// origins.  Which is exactly what I was proposing:

> We should only permit access to the whitelist off a strongly authenticated origin.
I think we just went full circle. The whitelist is the *ONLY* way to use screensharing. If it's linked to HTTPS, then we've just decided that you either use HTTPS or you don't get to use screensharing - at all. (The discussion on this is ongoing on dev-platform as far as I can tell)

Maybe this is expected and intended but I want to avoid conflation between the "persistent permissions" thing requiring HTTPS and "being able to use the feature at all" requiring HTTPS.
(In reply to Gian-Carlo Pascutto [:gcp] from comment #8)
> I think we just went full circle. The whitelist is the *ONLY* way to use
> screensharing. If it's linked to HTTPS, then we've just decided that you
> either use HTTPS or you don't get to use screensharing - at all. (The
> discussion on this is ongoing on dev-platform as far as I can tell)

There's two things here:

1. What we do now, which is limited access based on a whitelist.

2. What we do in general.

The whitelist is not an end state, it's a temporary condition only.  It's that way because we only have full-desktop sharing, and that opens a massive security vulnerability.

What I'm talking about is specifically related to the whitelist, as an embodiment of a persistent, origin-bound permission.  As such, if we can't strongly authenticate the origin, we should not permit the use of screensharing.  That true now, and in the future (and there is support for that position in the various standards groups.)  In the end state, I don't see any reason to prevent one-off use on unsecured origins if that means deviating from what the W3C Media Capture Task Force has defined.

If we can change their minds, that's different.
(In reply to Martin Thomson [:mt] from comment #9)
> (In reply to Gian-Carlo Pascutto [:gcp] from comment #8)
> > I think we just went full circle. The whitelist is the *ONLY* way to use
> > screensharing. If it's linked to HTTPS, then we've just decided that you
> > either use HTTPS or you don't get to use screensharing - at all. (The
> > discussion on this is ongoing on dev-platform as far as I can tell)
> 
> There's two things here:
> 
> 1. What we do now, which is limited access based on a whitelist.
> 
> 2. What we do in general.
> 
> The whitelist is not an end state, it's a temporary condition only.  It's
> that way because we only have full-desktop sharing, and that opens a massive
> security vulnerability.

I agree the whitelist is not an endstate.  What I don't know yet is a reasonable way to provide a) what people want, with b) enough security to avoid people machine-gunning themselves in the knees (security-wise), given c) the typical person using this.

One correction: we have a) full-screen sharing (most risky, and most commonly wanted), b) window sharing (also common, and also commonly the window they want to share is from a browser, c) app sharing (effectively the same as window, plus exposing popups).

> What I'm talking about is specifically related to the whitelist, as an
> embodiment of a persistent, origin-bound permission.  As such, if we can't
> strongly authenticate the origin, we should not permit the use of
> screensharing.  That true now, and in the future (and there is support for
> that position in the various standards groups.)

Agreed

> In the end state, I don't
> see any reason to prevent one-off use on unsecured origins if that means
> deviating from what the W3C Media Capture Task Force has defined.

I'd also state that users will have no concept of the security risks they're adding to themselves by allowing a sharing request from an un-authenticated site.  They have no idea now really for camera permissions, which is problematic in itself; but the impact has some limits to it (and it was a fait accompli by the time the WG started).

> If we can change their minds, that's different.
(In reply to Randell Jesup [:jesup] from comment #10)
> One correction: we have a) full-screen sharing (most risky, and most
> commonly wanted), b) window sharing (also common, and also commonly the
> window they want to share is from a browser, c) app sharing (effectively the
> same as window, plus exposing popups).

My preference is for b only.  The Cisco team working on this, who have a good amount of experience say that app sharing leads to nasty surprises, so they generally don't enable it.  And most people can live without desktop sharing.  I think that we could continue to provide full desktop sharing for whitelisted sites, but if the bulk of the web only gets window sharing, I think that's fine.
We don't need HSTS for whitelisted sites. As long as only https pages are whitelisted the same-origin policy and mixed-content-blocker should keep us safe enough.
Assignee: nobody → ekr
Status: NEW → ASSIGNED
Attachment #8487337 - Flags: review?(sstamm)
Attachment #8487337 - Flags: review?(martin.thomson)
Comment on attachment 8487337 [details] [diff] [review]
Require HTTPS for Screen/window sharing

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

::: dom/media/MediaManager.cpp
@@ +143,5 @@
> +    return false;
> +  }
> +  if (!isHttps) {
> +    return false;
> +  }

I'd initialize isHttps explicitly and combine the two if statements since they have the same return value, but yeah, looks right.
Attachment #8487337 - Flags: review?(sstamm) → review+
Attachment #8487337 - Flags: review?(martin.thomson) → review+
https://hg.mozilla.org/mozilla-central/rev/b0f9e80e8255
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
gum_test.html updated to warn on failure, then (timed) auto-reload to https:
Comment on attachment 8487337 [details] [diff] [review]
Require HTTPS for Screen/window sharing

Approval Request Comment
[Feature/regressing bug #]: screensharing

[User impact if declined]: no true privacy for screensharing (MITM/DNS-poisoning attacks can interpose themselves), leading to security attacks

[Describe test coverage new/current, TBPL]: Test page updated and manually tested.

[Risks and why]: almost no risk.

[String/UUID change made/needed]: none
Attachment #8487337 - Flags: approval-mozilla-beta?
Attachment #8487337 - Flags: approval-mozilla-aurora?
Comment on attachment 8487337 [details] [diff] [review]
Require HTTPS for Screen/window sharing

Beta+ and Aurora+
Attachment #8487337 - Flags: approval-mozilla-beta?
Attachment #8487337 - Flags: approval-mozilla-beta+
Attachment #8487337 - Flags: approval-mozilla-aurora?
Attachment #8487337 - Flags: approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.