Re: webRTC and Content Security Policy connect-src

I agree.

That is why my original proposal was to disable webrtc if CSP it's in use.

We could add an "webrtc" token for connect-src to enable it back knowing
the risks.

For what it seems, anything more fine grained would be difficult to get it
working.


Best regards
Sergio



El 12/1/2018 17:16, "Peter Thatcher" <pthatcher@google.com> escribió:

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