Re: webRTC and Content Security Policy connect-src

I didn't mean "ice:" for ICE servers, I meant domain-name ICE candidates.
But maybe "ice:" could work too.  Either way would require IETF work.

On Fri, Jan 12, 2018, 9:09 AM Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

> So, a combination of stun, turn urls and a new "ice:" url?
>
> That may work, depending on the combination it may be insecure, but as
> long as the defaults are restrictive (i.e. whitelisting) we would be safe.
> We could even include an unsafe option "ice:*" for the ones willing to take
> the risk.
>
> Regards
> Sergio
>
> El 12/1/2018 17:44, "Peter Thatcher" <pthatcher@google.com> escribió:
>
>> Actually, as I pointed out on the other threads (why are there so many?),
>> maybe domain-name-only remote ICE candidates and TURN servers and STUN
>> servers with whitelisted domains might work.  And that, while heavily
>> disabled, would at least allow PCs to whitelisted servers.
>>
>> On Fri, Jan 12, 2018, 8:30 AM Sergio Garcia Murillo <
>> sergio.garcia.murillo@gmail.com> wrote:
>>
>>> 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.
>>>>>
>>>>