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

[Colin Gallagher <[e-mail]>]

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