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

Colin Gallagher <colingallagher.rpcv@gmail.com> Fri, 26 May 2017 07:58 UTC

Return-Path: <colingallagher.rpcv@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F6D126FDC for <rtcweb@ietfa.amsl.com>; Fri, 26 May 2017 00:58:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwV7Qe5FPRJ7 for <rtcweb@ietfa.amsl.com>; Fri, 26 May 2017 00:58:10 -0700 (PDT)
Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8919A1242EA for <rtcweb@ietf.org>; Fri, 26 May 2017 00:58:10 -0700 (PDT)
Received: by mail-pf0-x235.google.com with SMTP id e193so4645454pfh.0 for <rtcweb@ietf.org>; Fri, 26 May 2017 00:58:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=K5gI7f3JW7jP2YazMu1SXWNOOF8WDWIGXVYkzNOuKNE=; b=uycOGPYdgD0kLBQ4quKrnGuAS+7cS7PDa93fh28rs6Cj8BuG1Bg92LAsqlh92nAngH HVjozCHE205D0IN3QXofJVgXHq0p4AhV2FZ6Mb+Rn4oHT/iEUYcCttxfEEer9jDp45Ht 4XT/KziXAD5ZFmoa/R52SF+JLlyW+acq04hhnYMSq0ost3DYN+lbHJGYSJ6ChmI8SGP4 Fh1n7ZhSe7qF9jrWnGukhZdFP/fOUIbb4/XWu/UK1GyCy7+QSoxur0JNvFFH6/VAB9Ld 1GmbtqsdEvZpnjiHFFyanl6+cIzFUxthNbPoxEof/iEVp416lx0ZDCpWgY2lnWA2YexT cffg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=K5gI7f3JW7jP2YazMu1SXWNOOF8WDWIGXVYkzNOuKNE=; b=LhlH2VfbY7dQmhO/Qupc0DUMzriwOCDm9oeGO+eM2SLH2lmprH7eD0P2I1PrZ148g6 W+hAu6AVPlEUkVwMkPJ9yJ9XozZMWYZd4REcXF+7dCA3qBujWpjAn+LIhNUJjzaFlj2+ 63BTtZSCu1DMbrH0RKU18ZJIdQTxhkehSTukZoCNdjAu47/kwDz9DKtp21KxGiNK5+JM Qqxd+vUFt3yvLm2QGN3qWOqUXqeuZcvi8F4Hmp/Vb6nG16kshWO8SLMcdbIrEZu0ljSe 79O8Z7v+Oapxk8ad6JbY6o665djjr4TETiDNWk4vvXKWFwf3u/fud1X9AwVUM0gHZg1x 7QcA==
X-Gm-Message-State: AODbwcC8PFppEogcO2AdwZpbMkGWiVCWKwL3Eung1cq2COwQmo3uZKrT 4JbCsz4fTcSevifyAP/JxaJzq6o88g==
X-Received: by 10.99.181.25 with SMTP id y25mr808391pge.192.1495785489894; Fri, 26 May 2017 00:58:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.179.161 with HTTP; Fri, 26 May 2017 00:58:09 -0700 (PDT)
In-Reply-To: <CAOJ7v-1Jk7Vqi1j_L7JFp4046AfzwTAwvbWF9hKWQwkZuJWnrA@mail.gmail.com>
References: <CABghAMiVwwDY0jE72XZRv2WhaEF53WnnFgjQu953eGqtR07vUQ@mail.gmail.com> <CAOJ7v-1Jk7Vqi1j_L7JFp4046AfzwTAwvbWF9hKWQwkZuJWnrA@mail.gmail.com>
From: Colin Gallagher <colingallagher.rpcv@gmail.com>
Date: Fri, 26 May 2017 00:58:09 -0700
Message-ID: <CABghAMgz+R=nXVCRKrxsoDQicR-CVaNdWq64HegCLHpOf1kHPQ@mail.gmail.com>
To: Justin Uberti <juberti@google.com>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c1b7fd6c912f5055068b2a2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/rJl8tdJG_dyPwMbNgOyFdl5P3Z0>
Subject: Re: [rtcweb] Request for New Security Review of WebRTC based on observed vulnerabilities
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 May 2017 07:58:15 -0000

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 <juberti@google.com> 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 <
> colingallagher.rpcv@gmail.com> 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
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>