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

[Bernard Aboba <[e-mail]>]

Based on your messages so far I am not clear what you are asking for the IETF RTCWEB WG to do. You have not filed any issues against the IP Handling document so it is not clear if you feel it needs to be changed or even what it is may sdonf. Nor are you posting your request to the SDO (W3C) that actually owns the API and reviews its privacy and security implications. 

> On May 26, 2017, at 11:14 AM, Colin Gallagher <[e-mail]> wrote:
> 
> It seems the consensus of the group here is essentially a refusal to further review and potentially redesign WebRTC to remove the serious security vulnerabilities that it presents to its users.
> 
> Thank you for your time.  I will not further respond to this thread.
> 
>> On Fri, May 26, 2017 at 10:49 AM, Justin Uberti <[e-mail]> wrote:
>> Colin,
>> 
>> As Eric mentioned, the group has reviewed this exact issue, and the aforementioned document represents the result of the review.
>> 
>> I am still not quite clear on the exact technical issue you would like to see addressed and why it is, as you claim, a serious vulnerability.
>> 
>> Comments inline.
>> 
>>> On Fri, May 26, 2017 at 12:58 AM, 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.  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
>>> 
>>> I typed about:config in the address bar
>>> I found the setting media.peerconnection.enabled
>>> 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, 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] 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), but
>>>        direct access to the Internet is also supported, WebRTC's STUN
>>>        [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).
>> 
>> The document discusses #1 and #3 in detail, and outlines mechanisms that can be used to address these cases if needed.
>> 
>> If, despite the findings in the document, you think that these are indeed serious problems, it would be good to outline exactly why.
>>> 
>>> 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.
>> 
>> To my knowledge, the document addresses these goals. If you believe Firefox is not conforming, please file a bug; if you think the document is in error, please point out where and why.
>>> 
>>> 
>>> 
>>>> 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, 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).  So as to mitigate this vulnerability, I changed settings in Firefox as follows:
>>>>> 
>>>>> I typed about:config in the address bar
>>>>> I found the setting media.peerconnection.enabled
>>>>> 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, 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