Re: webRTC and Content Security Policy connect-src

Why is this ICE-lite specific?   A controlling ICE agent will begin sending
data as soon as it had received a check response, regardless of whether or
not it has received a check yet.   And that happens for full clients as
well.

I think you need to go further and say something like "don't send data
until you get a check", which is like a reverse consent check.


But even that might not be good enough.   You could, for example, convey
information to the server simply by controlling the ports to which you send
checks, which is driven by the adding of remote candidates, which is
controlled by JS.

Even if we could prevent that, there is probably a way to convey
information by controlling the IP or port used for gathering server
reflexive or relay addresses via STUN or TURN.

How far down the rabbit hole of disabling things you want to go?




On Fri, Jan 12, 2018, 3:04 AM T H Panton <thp@westhawk.co.uk> wrote:

> In the call yesterday, I said I'd try and summarize the concerns that have
> been raised about 'Drive-by webRTC CSP' attacks.
>
> Content Security Policy on web pages allows a site developer to proscribe
> what their page can do.
> This is intended to mitigate the risks of XSS and other injection attacks.
>
>
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/connect-src
>
> This reduces exposure to included 3rd party scripts being tampered with at
> source
> e.g. if someone hacks https://webrtc.github.io/adapter/adapter-latest.js
>  - the page may not function correctly, but it should not be able to send
> sensitive
> data to domains that aren't whitelisted in the CSP connect-src header.
>
> This prevents a web-font supplier from capturing the credit card data from
> your
> e-commerce site shopping forms.
>
> The connect-src explicitly covers websockets. It does not mention
> DataChannels or webRTC.
>
> In principle you might not think that matters, since in order to set up a
> data-channel
> you need to perform an SDP exchange, and that SDP exchange would have to
> go through
> a whitelisted server.
>
> 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
> c) add a allow-ice-lite CSP
> b) add a CSP turn-servers whitelist (to prevent leakage via the
> credentials)
> c) test plain ICE to make sure it fails if the far side sends no valid
> requests.
> d) ensure that any new ICE api's don't make this mistake (worse)
>
> Thanks to ibc@aliax.net for starting the discussion and
> sergio.garcia.murillo@gmail.com for pointing me at CSP connect-src:
> https://twitter.com/ibc_tw/status/949993145978245120
>
> P.S.
> As you will see in the twitter thread, this isn't specific to the
> datachannel - one can exfiltrate data over DTMF or G711 perfectly easily.
>
> Tim.
>