Subject: [rtcweb] Notes on security for browser-based screen/application sharing

From: Eric Rescorla <[email-masked]>
Date: Mon, 11 Mar 2013 13:53:41 -0700

1. INTRODUCTION
WebRTC [0][1] already contains facilities for JavaScript applications
to acquire to the user's camera and microphone and either to directly
access the media or to send it elsewhere over a voice/video call.
This obviously presents security issues [2][3] and the consensus
approach is that any access to camera or microphone must only occur
with user consent. Current versions of Chrome obtain this consent once
and persist it indefinitely for a given site. Firefox obtains consent
for every request but will likely eventually add a persistent consent
feature.

One of the major applications of WebRTC-style technology is
videoconferencing and most videoconferencing applications offer either
"screen sharing" or "application sharing" or both. Unfortunately,
while the security properties of camera/microphone access are fairly
obvious to the user--though the properties of persistent permissions
may not be--the security properties of screen/application sharing are
far less obvious. It has been suggested by Adam Barth among others that
permissions should be stricter for screen sharing than for
camera/microphone access. This note provides an overview of the
relevant security issues and of the potential permissions/consent
mechanisms.

2. GENERAL SECURITY PROPERTIES OF SCREEN/APPLICATION SHARING
Technically, screen/application sharing is relatively simple. In
screen sharing, the conference sees whatever is on the user's display;
if there are multiple monitors, typically only one is shared. In
application sharing, the conference gets access to all the windows in
an application.

Because existing conferening products (e.g., WebEx) require some sort
of download/install experience, they end up with the permissions of a
native application. Thus, it doesn't really make sense to worry about
misuse of the sharing permissions specifically because the application
has free run of the user's machine. The security question then becomes
whether the user wishes to run the application at all, not whether he
trusts the application to see his screen specifically.

Even so, there are known security risks to this type of sharing,
mostly due to the user's misunderstanding/lack of thought about
the security properties. For instance:

* The desktop often contains icons that the user has forgotten
  about, including the names of files. These themselves can
  be confidential.

* Desktop notifications such as Growl for incoming messages,
  IMs, etc. can be get shared. These can also contain confidential
  information.

* Users often think of "application sharing" as "window sharing"
  and will have other sensitive documents open at the same
  time as the document they intend to be sharing.

I have heard reports of all of these issues (the first two are also
often seen in settings when the user is projecting their screen at
conferences and the like). Fundamentally, these are examples of user
error, though possibly combined with confusing interfaces. The users
generally understand that they have given the downloaded application
wide permissions. Because users' expectation for Web applications are
that they are safer, there is yet more space for confusion.

3. SECURITY OF SCREEN/APPLICATION SHARING IN THE WEB ENVIRONMENT
3.1. Threat Model
Huang et al.[4] describe the Web security guarantee as:

   Users can safely visit arbitrary web sites and execute scripts
   provided by those sites.

More generally, users expect that the browser will protect them from
malicious sites and that sites are isolated from each other.  (More on
the technical mechanisms below).

Obviously, granting permission to see the desktop breaches this
guarantee to some extent, since the user is granting the site (via the
browser) some very dangerous capabilities. Generally the intent is
that the user can understand the security impact of the permission he
is granting. As should be clear from the discussion above, this is
already not entirely so. However, in the Web environment the problem
is much worse because the user likely thinks that he is assuming
*just* the screen/application sharing risks without the corresponding
"full application privileges" risks. This is unfortunately less true
than one would like.

3.2. Background: Same Origin Policy
In order to isolate sites from each other, browsers implement what's
called the "Same Origin Policy" (SOP). The basic idea is that content
(scripts, HTML, etc.) that runs on one site cannot get access to
content from another site, except under very limited conditions.  For
instance, site A can:

- Run scripts from site B.
- IFRAME HTML from site B but not look at the content or output.
- Display images and videos from site B but not examine their
  contents.

[Note: I am ignoring CORS and WebSockets for the moment.]

The basic idiom here is that site A can cause content from site B to
be *displayed* but it can't access the content itself. This allows for
the construction of some kinds of composite Web sites (i.e., mash-ups)
but still allows for site isolation.

Many important Web security mechanisms depend explicitly on these
guarantees. For instance, consider a Web mail site which bases its
authentication on cookies and will therefore service any HTTP request
which contains the right cookie. Content from any other site can cause
the browser to emit the right HTTP request, but because of the
same-origin policy, it can't see the responses. This prevents random
sites from accessing your web mail.

3.3. Web-Specific Risks
At this point, the risk of combining screen sharing with the Web
environment should be obvious. SOP protection depends on denying
Web content access from site A to content from site B, but
because site A can cause content from site B to be displayed
on the screen, if A can see the user's screen then he can
close the loop and bypass SOP. (We assume below that either
the site is sharing the user's screen or that the browser is
the application being shared.)

3.3.1. SOP Violations for Visible Content
The most obvious attack vector is that the the site can see any
content that the user can see. All he needs to do is to open a window
with the URL of the relevant content and put it in view of the screen
sharing system. Note that the content only needs to be briefly visible
(long enough to be captured by the sharing code). Potential attacks
include:

- Capture the user's webmail (and potentially individual messages).
- Capture the user's "sitekey" anti-phishing picture. [6]
- View any confidential documents that the user has access to
  on the Internet or on their own computer.

In general, any resource which can be opened in a browser window
(if the browser is being shared) or in an external application
(if screen sharing is in use) can be accessed in this fashion.

3.3.2. SOP Violations for "Hidden" Content
The SOP issue extends beyond visible content. For instance, many sites
use secret tokens in HTML content to prevent Cross-Site Resource
Forgery (CSRF) attacks. The idea is that the token is available to
same-origin JS which then embeds it in any XHR requests it
performs. The site checks for presence of the token, thus preventing
content from other sites from performing operations which might have
side effects (even if they cannot see the response). While embedded in
the HTML, these tokens are hidden to avoid annoying the user.

Similar techniques to those described above can be used to bypass this
type of CSRF protection. Instead of loading the content directly in a
window, the attacker loads the HTML in a source view window (using the
view-source: scheme, which both Chrome and Firefox support). Since the
HTML source contains the CSRF token, the attacker can simply read it
off, and use it to mount CSRF attacks.

4. CONSENT/PERMISSIONS OPTIONS
A number of possible permissions models have been proposed.

1. The same permissions model as audio/video, namely a consent
   dialog with (optional?) persistent content. [the
   natural default.]

2. A similar permissions dialog to audio/video but with *only*
   one-time consent. [proposed by Cullen Jennings]

3. A "sysapps" [5] API in which the user had to go through an
   app store type install experience to enable sharing for
   each specific site. [proposed by Adam Barth and others]

There have also been proposals for hybrid designs, such as a
sysapps-style API that also requires an in-chrome permissions dialog
for every sharing instance. Another possible design would be a
"preferred site" desing in which certain sites could directly ask for
permission without an application install but other sites would need
to do an app store install experience.  (Like the Firefox Social API).

The argument for the less onerous permissions models is of course
reduced user friction. The argument for the more restrictive models is
that the set of permissions that is being granted to the web site is
really more similar to those of a Web application install (even though
the user does not know it) and that therefore the barrier to entry
should be more like that of an application (i.e., a curated,
authenticated app store).

ACKNOWLEDGEMENT
Much of this material came out of discussions with Adam Barth,
Cullen Jennings, and Randell Jesup but I may well have mangled it.

[0] http://dev.w3.org/2011/webrtc/editor/webrtc.html
[1] http://dev.w3.org/2011/webrtc/editor/getusermedia.html
[2] http://tools.ietf.org/html/draft-ietf-rtcweb-security
[3] http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch
[4] http://w2spconf.com/2011/papers/websocket.pdf
[5] http://www.w3.org/2012/09/sysapps-wg-charter
[6]
https://www.bankofamerica.com/privacy/online-mobile-banking-privacy/sitekey.go

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 22 Mar 2013 13:50:37 +0000

One comment on this from a requirements point of view…

Clearly sharking the "desktop" has far more security concerns that sharing a single applications such as PowerPoint. All the use cases I am interested in only need to share an application not a desktop. I think we should separate the handling of permissions along these lines. So I would be fine with "share desktop" needed an explicit grant of permission every time it was invoked (preferably by the user selecting this as part to choosing what to share in a browser chrome window). On the other hand, when sharing an application I might be OK with a persistent permission based on an install model but when I think about the real uses cases, I'm not sure that is needed if we have a good browser based dialog box to pick what will be shared. 

When the applications being shared is the browser there are also the additional problems as you point out. My view of the best way to solve these would be to scope the "application" being shared to the origin. What I mean by this is assume that I have my browser open to two webpages, one with an origin of gmail.com and the other to github.com and I am also running powerpoint and word. When the browser pops up a dialog box asking me what I wanted to share, it would give me 5 choices "Firefox (Gmail.com)", "Firefox (github.com), "Word", "PowerPoint", and "Everything" and let me pick. 

On Mar 11, 2013, at 2:53 PM, Eric Rescorla <[email-masked]> wrote:

> [6] https://www.bankofamerica.com/privacy/online-mobile-banking-privacy/sitekey.go
> 
> 
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 22 Mar 2013 07:17:21 -0700

On Fri, Mar 22, 2013 at 6:50 AM, Cullen Jennings (fluffy)
<[email-masked]>wrote:

> Clearly sharking the "desktop" has far more security concerns that sharing
> a single applications such as PowerPoint. All the use cases I am interested
> in only need to share an application not a desktop. I think we should
> separate the handling of permissions along these lines. So I would be fine
> with "share desktop" needed an explicit grant of permission every time it
> was invoked (preferably by the user selecting this as part to choosing what
> to share in a browser chrome window). On the other hand, when sharing an
> application I might be OK with a persistent permission based on an install
> model but when I think about the real uses cases, I'm not sure that is
> needed if we have a good browser based dialog box to pick what will be
> shared.
>
>
The main point of my note is that the user has basically no idea what
sharing
the browser means. I don't see how this is remediated by a dialog box
telling them that they are sharing the browser.

> When the applications being shared is the browser there are also the
> additional problems as you point out. My view of the best way to solve
> these would be to scope the "application" being shared to the origin. What
> I mean by this is assume that I have my browser open to two webpages, one
> with an origin of gmail.com and the other to github.com and I am also
> running powerpoint and word. When the browser pops up a dialog box asking
> me what I wanted to share, it would give me 5 choices "Firefox
> (Gmail.com)", "Firefox (github.com), "Word", "PowerPoint", and
> "Everything" and let me pick.

This doesn't sound very implementable. First, if you're sharing primarily
by pixel
capturing out of the window, trying to figure out which pixels represent
which
origins is going to be a huge pain for the implementor. Second, many sites
as a practical matter are composed of content from multiple origins
(images out of a CDN, domain sharding, etc.) The result of what you propose
is going to be that such sites will not render properly when shared. I
suspect that sites will simply ask for "The browser".

-Ekr

---

From: Ron <[email-masked]>
Date: Sat, 23 Mar 2013 02:07:49 +1030

On Fri, Mar 22, 2013 at 01:50:37PM +0000, Cullen Jennings (fluffy) wrote:
> Clearly sharking the "desktop" has far more security concerns that sharing a
> single applications such as PowerPoint. All the use cases I am interested in
> only need to share an application not a desktop. I think we should separate
> the handling of permissions along these lines. So I would be fine with "share
> desktop" needed an explicit grant of permission every time it was invoked
> (preferably by the user selecting this as part to choosing what to share in a
> browser chrome window). On the other hand, when sharing an application I
> might be OK with a persistent permission based on an install model but when I
> think about the real uses cases, I'm not sure that is needed if we have a
> good browser based dialog box to pick what will be shared. 
> 
> additional problems as you point out. My view of the best way to solve these
> would be to scope the "application" being shared to the origin. What I mean
> by this is assume that I have my browser open to two webpages, one with an
> origin of gmail.com and the other to github.com and I am also running
> powerpoint and word. When the browser pops up a dialog box asking me what I
> wanted to share, it would give me 5 choices "Firefox (Gmail.com)", "Firefox
> (github.com), "Word", "PowerPoint", and "Everything" and let me pick. 

Do you really only have 2 browser tabs and 5 things running on your computer?

If it was to offer me something like that on the machine I'm typing on right
now (which is the one I'd be most likely to want to share something on if I
did), then browser tabs alone would give me a few hundred checkboxes, and if
we add my entire desktop and all the things running on it, then we're well
into Over 9000 territory ...   and I'm not sure I'd _want_ my browser to have
easy access to those things anyway, at least not without a whole lot of clear
opt-in and easy opt-back-out-again going on.

If I was to say I wanted to share my PDF reader, would I really want to share
all of the many dozens of documents currently open in it with a single checkbox?
What is the 'origin' for those if they're all cached on my local disk?

I'm not saying you aren't sort of on the right track here, but that's a data
point for a real world system ...

  Ron

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 22 Mar 2013 15:44:17 +0000

A related question, apologies if this is well known
already, or it if fits more within the W3C than here.

Are there other things on the user's device that might
end up being shared? E.g. accelerometers or other sensors.
There have been papers demonstrating that access to such
information can reveal lots of things, e.g. passwords.

I also wonder what's supposed to happen to the camera
and mic if a screensaver kicks in. (Thinking again
that a password might be entered at that point and that
the remote end might be able to extract that from
noise/arm movement if the camera/mic are still on.)

S.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 22 Mar 2013 09:57:36 -0600

On Mar 22, 2013, at 8:17 AM, Eric Rescorla <[email-masked]> wrote:

> On Fri, Mar 22, 2013 at 6:50 AM, Cullen Jennings (fluffy) <[email-masked]> wrote:
> 
> The main point of my note is that the user has basically no idea what sharing
> This doesn't sound very implementable. First, if you're sharing primarily by pixel
> capturing out of the window, trying to figure out which pixels represent which

Yah, I get your point. Sad but I agree.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 22 Mar 2013 10:10:36 -0700

The other day Matthew suggested that his best solution for employee
motivation was to release a hungry lion into the office at random
times.  The more I think on the subject, the more this seems that this
is exactly what we are doing.

> suspect that sites will simply ask for "The browser".

The modern web reality is that any one page consists of content from
many different sources, so restricting to one source is impractical.
>From an implementation perspective, it might be possible to restrict
to untainted content (the content that the page origin can access),
but that would probably result in something that is virtually useless.
 Just like that interesting (redacted) document that contains
(redacted).

I suggested to EKR that perhaps we could devise an opt-out for truly
sensitive information using Frame-Options so that sensitive content
could be hidden, but even that seems a little weak.

---

From: Randell Jesup <[email-masked]>
Date: Fri, 22 Mar 2013 13:32:24 -0400

>   Just like that interesting (redacted) document that contains

Correct, and likely be be highly annoying and highly confusing to users.

It really does come down to a trust (or trust and verify) model.  Do you 
trust the JS application?  Can you verify the JS application is the one 
you think it is?  Is there any way to whitelist or blacklist 
applications (from the browser maker or by the user)?   If you're going 
to install/trust/whatever an app, is there an equivalent to 
virus/spyware scanning?

You might be able to (in screen/app sharing) lock out the ability to 
redirect the MediaStream to anywhere but a specific PeerConnection, and 
have chrome that tells you "this is being shared with a connection to 
<identity>" using the identity stuff already proposed, and in other ways 
leverage the "secure call" stuff ekr proposed in Boston.  However, 
there's the converse side at reception - you have to protect it there as 
well - no grabbing a copy from a <video> element, no looping it out to 
another peerconnection (without user consent), no recording (without 
user consent), no other way to access the content of the decoded stream.

Armoring a screenshare against leaks to the application will be tough, 
but it might (just) be possible.  Layering both mechanisms (trust and 
armoring) might be better than relying on just one.

I wonder if mechanisms like out-of-band passcodes (similar to what 
Remote Assistance uses IIRC) that one or both users must enter into the 
chrome might help.

Ah, such easy problems....

-- 
Randell Jesup
[email-masked]

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Tue, 26 Mar 2013 14:00:44 -0700

> information can reveal lots of things, e.g. passwords.

You mean like <https://bugzilla.mozilla.org/show_bug.cgi?id=681562>?

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 Mar 2013 21:15:08 +0000

> You mean like <https://bugzilla.mozilla.org/show_bug.cgi?id=681562>?

Yep. Are the use-cases in webrtc for that kind of sensor
data to be made available over the n/w or is it all handled
locally?

Ta,
S.

---

From: Ralph Giles <[email-masked]>
Date: Tue, 26 Mar 2013 14:37:21 -0700

> data to be made available over the n/w or is it all handled

Most sensor data can be passed through a DataChannel without any special
handling by WebRTC. There only needs to be a use case if it's a form of
data that makes sense to compress and transmit as audio or video.

 -r

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 26 Mar 2013 23:27:01 +0100

> data to be made available over the n/w or is it all handled

I think the DAP WG in the W3C is the right place to address APIs for 
sensor data.
They're one of the parent WGs of the Media Capture Task Force, which is 
charged with getting the specs right for getusermedia, so one would 
assume they're aware of the discussions there.

But in my opinion, neither the WEBRTC WG nor the RTCWEB WG have this in 
their charters.

I advocate separation of concerns; if people want to work on this, go there.