getUserMedia permissions in iframe

[Trond Kjetil Bremnes]

I'm an engineer at appear.in, an up-and-coming video chat service, and I'm curious about a security aspect of the getUserMedia permission in iframes. We've experience something that we regard as a fairly serious security bug, but we don't really know if this is a bug in the webrtc specification or if it is a Chrome implementation bug.

Right now, in Chrome, the behaviour of embedded getUserMedia requesting sites is that if getUserMedia powered site A gets embedded by site B, site B will have camera permissions without having to request it. While the actual media stream will not leak across the domains, it has still started the webcam (permissions already granted). And in appear.in's case, which works similarly to App RTC, you will have initiated a broadcast.

All you'd need to do, as a malicious website author is to hide an iframe loading a video room on the page somewhere. Or, theoretically deploy an ad through an ad network. And presto – you can watch the visitors on your site without the consent or knowledge from the visitor.

- And quite honestly, for all we know, it may already be used for such purposes.

Given a sufficiently popular web service, where a substantial amount of people have allowed camera or microphone access, I fear that this will become a huge security issue. And as a business, our goal is obviously that every person and their dog has visited and used our site – and in the process of using it allowed webcam access.

We don't want to disallow use of appear.in through iframes, in fact we love it when people create new services based on it. But if this means that we let nefarious web authors to peek at their visitors, we'll have to disallow it. As should every similar service.

What I can't seem to figure out is if this is a Chrome issue, or a spec issue.

It looks like Microsoft Edge does what I consider to be the correct thing:

https://blogs.windows.com/msedgedev/2015/05/13/announcing-media-capture-functionality-in-microsoft-edge/

Firefox requires you to request the permission every time, so it isn't an issue. Though the dialog doesn't disclose who requests the permission, so I don't know what will happen if/when they decide to start remembering who you granted access to.

Is this a Chrome bug or is it a spec bug?

[Harald Alvestrand]

This was a topic of long discussion in the WG .... the latest resolution (you can follow the links from https://github.com/w3c/mediacapture-main/pull/362 to see the discussion) was that each Document has an "user media allowed" flag, which the HTML folks promised to set to false by default for different-origin embedded iframes, and specify a mechanism for setting it to true (for the case where the embedder really wants to pass the permission to the iframe).

I don't think all the HTML pieces are in place yet, but it makes sense to file this as a Chrome bug.

The number of people that can potentially be affected is strictly less than the number counted by https://www.chromestatus.com/metrics/feature/timeline/popularity/1145 (that feature doesn't distinguish between cross-origin and same-origin iframes), so the impact of forbidding it should not be large.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/05a40281-89d6-457a-ade4-63d209f85671%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[jib]

The embedder is the attacker in this case, and Trond said they don't want to disallow use of appear.in in iframes.

I believe the spec solved this in https://github.com/w3c/mediacapture-main/pull/309 but browsers haven't caught up.

The trickiest part may be to figure out who to say is requesting permission in the prompt. Neither site A nor site B seem sufficient, as in general users may trust either more than the other:

  - MaliciousSite.com with iframe > https://appear.in/MaliciousSiteRoom123456
  - NYTimes.com with iframe > https://spammyAds.com/NYTimesImpersonator123

.: Jan-Ivar :.

[Harald Alvestrand]

Seems I did not read original post carefully enough.

Multiple attacks here.... consider attacker E and videocall site B, where B has permission.

- A embeds E: If E gets permission, that's bad. That's the attack that I thought we were talking about.

- E embeds A, and directs A to call a site E controls: That's bad.

There are 2 lines of defense here that appear broken:

- When evaluating A's permission, it was supposed to use E's origin as part of the input. (Some people want to use *only* E's origin.) This language was removed from getusermedia when we decided to punt the setting of the "user media enabled" flag to HTML5.

- There's advice against using "embed callee in URL" services - because these can be used to mount exactly the attack envisioned here. When the callee is established in a dialog, it's harder for the embedder to force the embedee to call a specific destination. (Couldn't find the text on a Saturday morning.)

I think the first (failing to check E's permissions) is a Chrome bug.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/b3c9fc13-27b6-4987-bb16-bd34ff31b257%40googlegroups.com.

[Sergio Garcia Murillo]

To avoid second case, the only viable solution is to only allow gUM requests on trusted user click/touch events, which I think was already proposed.

Best regards
Sergio

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAOqqYVGf0MrDh%3D-RwN40AA0C9pJkqEwQ2-i5COFAKHVrf4FiDg%40mail.gmail.com.

[stefanh]

This sounds like a Chrome bug.

[jib]

Sergio, not so. The current spec handles this:

  4. Let originIdentifier be the [HTML51] top-level browsing context's origin.

  5. If the current [HTML51] browsing context is a [HTML51] nested browsing context whose origin is different from originIdentifier, let originIdentifier be the result of combining originIdentifier and the current browsing context's origin.

  6. For the origin identified by originIdentifier, request permission for use of the devices, ...

I.e. double-key to both A and B. So the spec seems fine. This is an implementation bug.

[jib]

On Saturday, August 27, 2016 at 2:15:39 AM UTC-4, Harald Alvestrand wrote:

- There's advice against using "embed callee in URL" services - because these can be used to mount exactly the attack envisioned here. When the callee is established in a dialog, it's harder for the embedder to force the embedee to call a specific destination. (Couldn't find the text on a Saturday morning.)

It seems unrealistic to outlaw deep links here. Being able to join a meeting - from e.g. an email or a chat room - with a single click is fantastic so I doubt that use-case will ever go away.

As I've already mentioned, double-keying to both sites - as the spec mandates - and present that somehow in the permission prompt, should solve this problem.

IMHO Chrome should give up on user-gesture as a panacea to permission problems in their own browser, as that passes the buck to web developers, which in turn - because of Chrome's dominance - ends up affecting other less exposed browsers.