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

[Iñaki Baz Castillo <[e-mail]>]

It seems to me that you don't want WebRTC. For WebRTC to work IPs must be
exposed. So not sure what you are asking for.

El 26/5/2017 9:58, "Colin Gallagher" <[e-mail]>
escribió:

> 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
>
>