[webrtc-pc] restricting available media types in the constructor (#2561)

fippo has just created a new issue for https://github.com/w3c/webrtc-pc:

== restricting available media types in the constructor ==
WebRTC attempts to treat SDP as an opaque blob and generally assumes that developers do not need to inspect the SDP before passing it to setRemoteDescription. Which is quite questionable from a security point of view.

This can have unexpected consequences. Suppose you have an audio-only application. Now you get an offer that includes video because there was a H264 vulnerability. If that gets negotiated and decodes H264 bad things may happen in quite unexpected ways which have blown up in the past:
  https://bugs.chromium.org/p/webrtc/issues/detail?id=11013
  https://bugs.chromium.org/p/project-zero/issues/detail?id=1936
and just now
  https://googleprojectzero.blogspot.com/2020/08/exploiting-android-messengers-part-3.html
which explicitly mentions the scenario:
```
To do this, I wrote a Frida script that hooks nativeCreateOffer in Java, and makes a call to createDataChannel
before the offer is created. This was sufficient to enable SCTP on both devices, as the target device determines
whether to enable SCTP based on the SDP provided by the attacker.
```
Similarly, datachannel-only applications may not expect SDP with audio or video m-lines.

To mitigate this, add a new property to the RTCConfiguration:
```
const pc = new RTCPeerConnection({supportedMediaTypes: {
    audio: true,
    video: true,
    data: true,
  }
});
```

Behaviour:
When processing a remote description reject any m-line where supportedMediaType[mline.type] is false
if supportedMediaType[audio or video] is false and addTrack is called with a track of that kind throw an error. Similar for addTransceiver.
if supportedMediaType[data] is false and createDatachannel is called, throw an error

This can be polyfilled.

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2561 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 6 August 2020 18:28:09 UTC