- From: T H Panton <thp@westhawk.co.uk>
- Date: Fri, 12 Jan 2018 12:04:20 +0000
- To: Iñaki Baz Castillo <ibc@aliax.net>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>, Cullen Jennings <fluffy@iii.ca>
> On 12 Jan 2018, at 11:53, Iñaki Baz Castillo <ibc@aliax.net> wrote: > > 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. > > Sorry, I wasn't clear - a complete solution needs _all_ of my steps. They aren't alternatives. Here is the thinking: An OA round-trip would be covered by existing connect-src policies ice-lite breaks the need for an OA round-trip So any page that sets a CSP connect-src should not be able to do ice-lite (a) If you want to enable ice-lite on CSP protected pages, you add an allow-ice-lite CSP directive (b) Part (c) is to cover the risk that over-enthusiastic plain ice servers may connect a plain ice session without ever seeing a request (containing their ufrag). > > 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. That's also possible. but that's an IETF side solution. > > 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. True. > > > -- > Iñaki Baz Castillo > <ibc@aliax.net>
Received on Friday, 12 January 2018 12:04:46 UTC