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

[Eric Rescorla <[e-mail]>]

Colin,

I'm not really sure what you think the new information is here.

The draft that Justin referred to reflects the consensus view of the RTCWEB
WG
about the best balance between privacy and usability, and yes, it does
result in
the server learning your default RFC 1918 address, so it's not surprising
that
accounts for the results you are seeing with Firefox. If you think there's
a defect
where Firefox isn't conforming to the spec, then you should file a bug, but
otherwise I'm not really seeing what there is for the WG to reconsider

-Ekr


On Fri, May 26, 2017 at 3:58 PM, Colin Gallagher <
[e-mail]> wrote:

> Justin,
>
> It's my understanding that various browsers have made an attempt to
> conform to the recommendations in the document that you have provided
> <https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-03>.
> Unfortunately, at least in Firefox (the most current version) so far as I
> can tell, there is a serious vulnerability.  To be more specific, the
> problem was observed in my operating system with my current browser, which
> is Ubuntu 16.10 64-bit with Firefox 53.0.2 (64-bit).  The browser does not
> address the WebRTC problems by default.
>
> The stackexchange page that I cited originally is actually not outdated in
> the sense that its method of measuring whether or not the WebRTC
> vulnerability exists on a given system is still intact and works.  The
> stackexchange page suggests two pages to determine whether or not you have
> leakage / WebRTC related vulnerability.  These pages are:
>
> 1) Browser leaks test for WebRTC https://browserleaks.com/webrtc
> 2) IP Leaks https://ipleak.net/
>
> Currently for Browser leaks test for WebRTC (due to that I have again
> changed settings in my system so that I will not have to be exposed to this
> vulnerability) the settings show up on the page as:
> RTCPeerConnection×False
> RTCDataChannel×False
> ORTC (Microsoft Edge)×False (for example....)
>
> And under IP leaks, it currently shows "No leak, RTCPeerConnection not
> available."
>
> *That is because:*
>
> (A) I have (again) changed my settings in about:config back to the
> following
>
>
>    1. I typed *about:config* in the address bar
>    2. I found the setting *media.peerconnection.enabled*
>    3. I set it to *false  (it was previously set at true, so as to allow
>    WebRTC to work, but this exposed information which I would not have wanted
>    to be exposed)*
>
> (B) And I also have changed my settings back to the following
>
> in the WebRTC 0.1.3 extension for Firefox I have set it to no longer
> expose my real IP address as well as no longer allowing the following:
>
> a. navigator.getUserMedia
> b. window.MediaStreamTrack
> c. window.RTCPeerConnection
> d. window.RTCSessionDescription
>
> To be clear, *these mitigations that I have employed above would be
> unnecessary if WebRTC had not been designed in such a manner that it so
> clearly exposes so much user information.*
>
> In the document you provided
> <https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-03>, titled
> "WebRTC IP Address Handling Requirements - draft-ietf-rtcweb-ip-handling-03,"
> it is stated that:
>
> *"1. If the client is behind a NAT, the client's private IP addresses,
> typically [RFC1918 <https://tools.ietf.org/html/rfc1918>] addresses, can be
> learned. *
>
>
>
> * 2.  If the client tries to hide its physical location through a VPN,
>        and the VPN and local OS support routing over multiple interfaces
>        (i.e., a "split-tunnel" VPN), WebRTC will discover the public
>        address for the VPN as well as the ISP public address that the
>        VPN runs over.
>
>    3.  If the client is behind a proxy (a client-configured "classical
>        application proxy", as defined in [RFC1919], Section 3 <https://tools.ietf.org/html/rfc1919#section-3>), but
>        direct access to the Internet is also supported, WebRTC's STUN
>        [RFC5389 <https://tools.ietf.org/html/rfc5389>]checks will bypass the proxy and reveal the public
>        address of the client."*
>
> All of these are obvious vulnerabilities and serious problems (not only #2 as the document suggests).
>
> It is stated in the document that,
>
>
>
> *"we want to avoid solutions that disable WebRTC or make it harder to use."*
>
> Yet, so far as my observations of WebRTC in the current version of Firefox with Ubuntu 16.10 have shown,
>
> there appears to be no other choice other than to disable WebRTC because its use completely compromises
>
> privacy and thus makes all other aspects of your system more difficult generally.
>
> It is stated in the document you cited that the goals here are to "Provide a privacy-friendly default behavior which strikes the
>       right balance between privacy and media performance for most users
>       and use cases. (and) For users who care more about one versus the other, provide a
>       means to customize the experience."
>
> This has clearlly not been accomplished in the context of Ubuntu 16.10 64-bit with Firefox 53.0.2 (64-bit).
>
> Hence my request for a new security review of WebRTC based on observed vulnerabilities.
>
>
>
>
> On Thu, May 25, 2017 at 1:04 PM, Justin Uberti <[e-mail]> wrote:
>
>> 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
>>>
>>>
>>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>