W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2018

Re: webRTC and Content Security Policy connect-src

From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Fri, 12 Jan 2018 12:53:42 +0100
Message-ID: <CALiegfnLX6cf4Ggwjon4LSgC0S3qu41g_Nhy-H3sSvpM9wcbew@mail.gmail.com>
To: T H Panton <thp@westhawk.co.uk>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>, Cullen Jennings <fluffy@iii.ca>
Thanks Tim,

Some comments about the ICE-Lite security/privacy issue below:

On 12 January 2018 at 12:01, T H Panton <thp@westhawk.co.uk> wrote:
> It turns out in the case of ice-lite the browser does not verify that the remote party has
> ever seen it's SDP - ICE responses do not require the requester's ufrag or pass.
> This means that the malicious javascript does not need to send an answer to a
> cooperating server.
> So it would be possible to bury static SDP for an ice-lite offer in malicious javascript.
> The offer would point to a malicious server that implemented ice-lite on a fixed port
> (for example) and accepted data channels without checking the DTLS fingerprint.
> The javascript would apply this to a peerconnection and drop the generated answer in the
> bit-bucket.
> The malicious javascript can now inspect the page DOM and send all the form values it
> finds over a datachannel to the malicious server. Despite the fact that the conscientious developer
> had configured connect-src to mitigate this risk.
> At the heart of this is that ice-lite breaks the conceptual linkage between the 5 tuple and the
> page origin.

> Proposal:

> a) Ban ice-lite on pages with any CSP set

Too hard to understand the rationale.

> c) add a allow-ice-lite CSP

Even harder to understand IMHO.

> c) test plain ICE to make sure it fails if the far side sends no valid requests.

In ICE Lite the remote won't send requests at all.

A solution coming to my mind would be:

1. The browser signals its ice-ufrag to the remote (via HTTP/webSocket, etc).

2. The browser then send STUN Binding Requests (as always, with the
remote ice-ufrag, etc) to the remote ICE Lite endpoint.

3. The remote MUST reply to those Binding Requests with, somehow, the
sender's ice-ufrag included (and fingerprinted) into the STUN

4. Upon receipt of the ICE response, the browser MUST verify whether
the ICE response has the local ice-ufrag. Otherwise it's dropped.

So, in the use case above, the browser MUST signal its local
ice-ufrag, which means that it must use HTTP or WebSocket (yep, or
TURN credentials, but that's a different story), so existing CSP rules
(content-src) join the party and, if set, would make it impossible for
the attacker JS to provide the remote endpoint with its local
ice-ufrag. End of the story.

These steps would make both, Full ICE and ICE Lite, have the same
security concerns.

NOTE: Of course, for this to work, calling pc.setLocalDescription()
with mangled ice-ufrag should NOT work.

Iñaki Baz Castillo
Received on Friday, 12 January 2018 11:54:41 UTC

This archive was generated by hypermail 2.3.1 : Friday, 12 January 2018 11:54:41 UTC