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

Re: webRTC and Content Security Policy connect-src

From: T H Panton <thp@westhawk.co.uk>
Date: Fri, 12 Jan 2018 12:04:20 +0000
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>, Cullen Jennings <fluffy@iii.ca>
Message-Id: <31377F15-DD05-4E0C-A40B-CAB43EC131E1@westhawk.co.uk>
To: Iñaki Baz Castillo <ibc@aliax.net>


> On 12 Jan 2018, at 11:53, Iñaki Baz Castillo <ibc@aliax.net> wrote:
> 
> 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.
> 
> 

Sorry, I wasn't clear - a complete solution needs _all_ of my steps. They aren't alternatives.

Here is the thinking: 
An OA round-trip would be covered by existing connect-src policies
ice-lite breaks the need for an OA round-trip
So any page that sets a CSP connect-src should not be able to do ice-lite (a)
If you want to enable ice-lite on CSP protected pages, you add an allow-ice-lite CSP directive (b)

Part (c) is to cover the risk that over-enthusiastic plain ice servers may connect a plain ice session without
ever seeing a request (containing their ufrag).

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


That's also possible. but that's an IETF side solution.


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

True.
> 
> 
> -- 
> Iñaki Baz Castillo
> <ibc@aliax.net>
Received on Friday, 12 January 2018 12:04:46 UTC

This archive was generated by hypermail 2.3.1 : Friday, 12 January 2018 12:04:46 UTC