Re: [rtcweb] Request for New Security Review of WebRTC based on observed vulnerabilities

[Justin Uberti <[e-mail]>]

Colin,

This is an important topic, and the group has reviewed this situation in
detail. The results have been written up in this document
<https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-03>, and to my
knowledge most browsers that support WebRTC currently conform to its
recommendations.

However, I'm not totally clear on your specific technical concern. You
linked to an (now outdated) stackexchange page, but could you provide more
detail about the specific situation you are concerned about?

Justin

On Wed, May 24, 2017 at 5:35 PM, Colin Gallagher <
[e-mail]> wrote:

> To:  IETF RTCWeb WG
>
> From:  Colin Gallagher
>            https://www.linkedin.com/in/colingallagher
>            https://lifeboat.com/ex/bios.colin.gallagher
>
> Request for New Security Review of WebRTC based on observed
> vulnerabilities in certain examples
>
> Dear IETF RTCWeb WG,
>
> This request relates to WebRTC.  The WebRTC is in draft at
> https://w3c.github.io/webrtc-pc/ and is described also at
> https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API#
> WebRTC_interfaces
>
> There are certain examples where the use of WebRTC has presented security
> vulnerabilities.  While not exhaustive, there are two I wanted to mention
> that I had been exposed to recently.
>
> 1) The use of a video conferencing service which relies upon WebRTC (that
> is a well established service)
> 2) The examination of a browser based WebRTC version of a decentralized
> exchange (that is currently under development)
>
> In both cases the security vulnerability which is described below was the
> result of the use of WebRTC.
>
> The problem under consideration is as follows:
>
> As per the first example (the video conferencing service), recently I came
> upon a vendor who shall remain unnamed who uses WebRTC as the backbone for
> their video conferencing service.  As a result, I found I was unable to
> access the service in question without disabling some security settings
> which I would have preferred to leave intact.
>
> My system is (based on what the aforementioned service detects)
> Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:53.0) Gecko/20100101
> Firefox/53.0.  This is Ubuntu 16.10 64-bit with Firefox 53.0.2.
>
> However, quite some *long* while back I disabled WebRTC because of the
> security vulnerability (described in part here on information security
> stack exchange
> <https://security.stackexchange.com/questions/82129/what-is-webrtc-and-how-can-i-protect-myself-against-leaking-information-that-doe>).
> So as to mitigate this vulnerability, I changed settings in Firefox as
> follows:
>
>
>    1. I typed *about:config* in the address bar
>    2. I found the setting *media.peerconnection.enabled*
>    3. I set it to *false*
>
> Unfortunately, this setting does not allow Firefox to work with the video
> conferencing service in question, which relies entirely on WebRTC.
>
> So I had to go back in and change the media.peerconnection.enabled setting
> to *true* in Firefox in order to get it to work with the service in
> question. While this enabled me to conference with teams that desire to use
> the video conferencing service that rely wholly upon WebRTC, it concerns me
> because of the security vulnerability.
>
> One suggested mitigation was having NoScript, but using NoScript was not
> helpful (you generally need to disable it for the site you are viewing that
> relies upon WebRTC, in order to obtain any functionality, and whether
> NoScript is off or on, WebRTC still causes the vulnerability of leaking
> information as previously described).
>
> Furthermore, upon reload of the browser, even after setting
> media.peerconnection.enabled to *true*, the video conferencing service
> wouldn't work until I installed the WebRTC 0.1.3 extension for Firefox and
> set it to expose my real IP address as well as allowing the following:
>
> a. navigator.getUserMedia
> b. window.MediaStreamTrack
> c. window.RTCPeerConnection
> d. window.RTCSessionDescription
>
> That seemed to me to be a direct consequence of the persistent and ongoing
> security vulnerability in WebRTC.
>
> I contacted the video conferencing service provider and their solution was
> simply to state that "If the peer to peer connection is of concern, you can
> utilize our premium version which will route traffic through a forwarding
> server with in our environment that handles the processing of the video and
> sound of all users in the conference and send it to each user individually
> rather than using a peer to peer connection."  In other words, they expect
> that people should have to pay in order to mitigate this WebRTC security
> vulnerability
> <https://security.stackexchange.com/questions/82129/what-is-webrtc-and-how-can-i-protect-myself-against-leaking-information-that-doe>,
> because they are unwilling to design to protect all users from it.
>
> In a similar fashion, in the second example of the browser based WebRTC
> version of a decentralized exchange, the user's financial information is
> periodically exposed as a result of the information leakage which is
> presently caused by WebRTC.  (Fortunately, this browser based WebRTC
> decentralized exchange is under development and is not currently open to
> actual usage.)
>
> Although undoubtedly this has been discussed here before, I am asking that
> WebRTC security issues be reconsidered and that a new security review be
> done to ameliorate or eliminate this problem in terms of WebRTC leaking
> this information.  It is my view that WebRTC should be further designed and
> developed with an eye to mitigating this serious problem, so that users of
> services which might rely partially or wholly upon WebRTC would not have to
> be concerned about such information leakage.
>
> Respectfully,
> Colin Gallagher
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>