Re: webRTC and Content Security Policy connect-src

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

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
<ibc@aliax.net>

Received on Friday, 12 January 2018 11:54:41 UTC