Re: webRTC and Content Security Policy connect-src

Hi Martin,

I would also be in favor of a master webrtc on/off switch for CSP as the 
one you are proposing, and in fact it was in one of my original proposals.

However it was noted by some people that they would not accept it as 
they would like to have a more fine grained control switch. I believe 
that it makes quite a lot of sense as for the kind of deployments in 
which you would like to set CSP and still be able to use webrtc, 
requiring that all media goes via server (SBC, turn server, recording 
server, SFU) is not an uncommon requirement.

Best regards
Sergio


On 15/01/2018 4:33, Martin Thomson wrote:
> I think that you are assuming that the server isn't cooperating with
> the attacker.  I don't think that's a necessary constraint.  On the
> contrary, I think that you have to assume that the server is willing
> to generate and accept whatever signals necessary to exfiltrate data.
>
> Concentrating on ICE-lite doesn't really help much here.  It's true
> that the attacker might be unable to exfiltrate an ICE password or
> ufrag for a genuine session using legitimate channels, but the attack
> model here assumes that the attacker is able to run script.  Such an
> attacker could hard-code values for these in both script and server.
>
> To Sergio's suggestion to add a bunch of rules to the grammar
> (ice:192.0.2.33 stun:192.0.2.34 turn:192.0.2.35).  Those area each
> then origins, and would require an RFC 6454-style definition.  As I
> said on the issue, there doesn't seem to be any significant functional
> difference between any of these AND determining the address of peers
> ahead of time is unlikely to be feasible.  A simple rule prohibiting
> webrtc entire seems more operationally feasible.
>
> That would have the effect of disabling gathering with
> browser-configured STUN and TURN servers, but I think that's a
> manageable loss.
>
> It would also not allow certain sites to more tightly control peers
> when they do use WebRTC.  I concede that this will affect sites that
> operate WebRTC only to servers.
>
> My initial proposal (from 2014!) was to add a special label
> 'webrtc-data' for 'connect-src', which would be prohibited unless
> present (or unless '*' is in the list).  I'm convinced that ICE is
> worth safeguarding if exfiltration is part of your threat model (as is
> the case for CSP today, I don't remember what it was like back in
> 2014).  Thus expanding the name to include all WebRTC makes sense.
>
> (Re: Roman's suggestion about identity.  Though it would be nice if we
> could do something to restrict communications based on identity,
> identity can't help here.  It takes effect too late in the process.)
>
>
> On Fri, Jan 12, 2018 at 10:01 PM, 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.

Received on Monday, 15 January 2018 09:31:33 UTC