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

Colin Gallagher <colingallagher.rpcv@gmail.com> Thu, 25 May 2017 00:35 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 BC294128C81 for <rtcweb@ietfa.amsl.com>; Wed, 24 May 2017 17:35:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.702
X-Spam-Level:
X-Spam-Status: No, score=0.702 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 MQJZYYQ9j2He for <rtcweb@ietfa.amsl.com>; Wed, 24 May 2017 17:35:18 -0700 (PDT)
Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (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 499941200C5 for <rtcweb@ietf.org>; Wed, 24 May 2017 17:35:18 -0700 (PDT)
Received: by mail-pf0-x231.google.com with SMTP id 9so150544935pfj.1 for <rtcweb@ietf.org>; Wed, 24 May 2017 17:35:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=8o4kvxad1K9qNe2bTokMhrq1YU2naaYLnqcMsx70F/c=; b=OItBjxXTAIqiqeO7pFvQevo9zGfkqXfI/DLBUh6QkOMXjx7nKajHxZqpFQp+4Ayqaz Z+Ina9QU2uXSuwsS5apLzH6wnEpMC91uAdFov/yakYWFuQf1Lt/gVOgRLEnPEMU9u5d9 V2XN1u+fVIR5Udn2lTNVCfX/3+mOQspG7/gZHjlq4s+CYe6EXd6I6P9eZt7crzCa6+lr BtJsjUz8ix+6W+QNYBIJMMzXUGAtgouGhLPcBd8rUB+RK3t2P/c9iZj2HFOXMg/nDA3p JPEJOFFny5cbNs1UH4kD81C9NNMCkcNKE4Ip/k9IAd3d4hXbt5SnbxbMoJKu71TwOrBp bP2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=8o4kvxad1K9qNe2bTokMhrq1YU2naaYLnqcMsx70F/c=; b=YfhrLPM6f0gg29lJjXBOUWo1tr87bVlYBG1hVF9cvu+lOPB3F8RHsElWULJnOIb/dD XcH1YFjvAgiuiVSe7/hcITdxdCug4MK0TFE5x3VHDOW1Oqv+UaPvyQ1GCmeY5PSckCjt KTXjBLCUjjm+M3iRzbfmOjLm5xma17UZc4/ipQPIbonQhA3ADLhdFKw1tXHHRG+wC3z4 w8cRs8d+ts8bnKQPM3l7iBqWVq+pWhZJdpZRVXhqzgTOjAjR/BTxd9tt0dO7qxugkVLn 1XHXq8HcPWlCFzUFVQKKNPaXRlYD0Ku10aOevXPpMtRtY+Mmb46IsS2g3nVbCRBsesJ7 k2tA==
X-Gm-Message-State: AODbwcATNMKJ5GsuuVuaqOInu0MMUDu4hdLlHPtvRur4k6obrHxggBHo Imz2Ed3QuB/lkGSZVyR+ve5GoJo1b/HEAHM=
X-Received: by 10.99.160.17 with SMTP id r17mr29222509pge.95.1495672517687; Wed, 24 May 2017 17:35:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.166.111 with HTTP; Wed, 24 May 2017 17:35:17 -0700 (PDT)
From: Colin Gallagher <colingallagher.rpcv@gmail.com>
Date: Wed, 24 May 2017 17:35:17 -0700
Message-ID: <CABghAMiVwwDY0jE72XZRv2WhaEF53WnnFgjQu953eGqtR07vUQ@mail.gmail.com>
To: rtcweb@ietf.org
Content-Type: multipart/alternative; boundary="f403045e38a41e01a105504e6529"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/Ir7FfOFGqczHRxJQuWWK6-3vMHs>
Subject: [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: Thu, 25 May 2017 00:35:21 -0000

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