-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
restricting available media types in the constructor #48
Comments
@fippo Would it be possible to also use this to force a certain codec? We have setCodecPreference but somewhat awkward to use if you are just doing an answer and not creating any transceivers yourself. I see a lot of people who only want H264 (or vpx). Even if people don't agree with their rationale would be possible to support it with this. |
@Sean-Der no, i think setCodecPreferences is the right api for that use-case. This proposal is aiming for defense-in-depth. |
Makes sense! One worry I have is that this won’t get used that often. Since it is opt-in and developers will not notice behavior changes if it gets removed by accident. |
I thin @Sean-Der raises a good point here. While I understand the good intention here, this will add more complexity to the browser implementations while I'm not fully convinced yet how many developers would actually use this. As the effort to implement this is probably not very high I think it could be added, but I'm not fully convinced yet that it is worth it. BTW another way to accomplish the same would be for the application itself to scan the remote SDP for unwanted media types and bail. |
Yes, the polyfill I had simply overwrote SRD and then did those manipulations. What we've been telling people for years is this:
and JSEP is saying
If we say this, we should also note the risks of doing so. |
I think this is a good idea and the location (an object on construction of I'm not sure we should complain about the added complexity by it considering what a bag of surprises SDP can be for security if left unfiltered. This API addition is really only the equivalent of a bouncer and I think we should be able to manage that. Heck, perhaps it's even a good idea to be forced to at least virtually untangle More delicate constraints already exist in other places such as the transceiver API which I think is a good model to follow when it comes to exposing more options in other places (say SCTP settings). |
For process reasons, I think this should be a PR on webrtc-extensions. |
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:
Similarly, datachannel-only applications may not expect SDP with audio or video m-lines.
To mitigate this, add a new property to the RTCConfiguration:
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.
The text was updated successfully, but these errors were encountered: