Closed Bug 1531904 Opened 5 years ago Closed 5 years ago

RTCPeerConnection.createDataChannel doesn't do a very good job of validating stream ids

Categories

(Core :: WebRTC: Signaling, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
mozilla68
Tracking Status
firefox68 --- fixed

People

(Reporter: bwc, Assigned: bwc)

References

(Blocks 1 open bug)

Details

Attachments

(5 files)

https://jsfiddle.net/jhbLk2on/

We seem to be relying entirely on webidl to do checking for us, but webidl does not seem to be upset when -1 is used to init an unsigned short. We are also not checking for 65535 as the spec requires.

Rank: 25
Priority: -- → P3

It seems to me that our hands are a little bit tied here; either this is a bug in our implementation of webidl, or the webidl spec makes it impossible to detect integer overflow when initting a webidl dictionary.

jib, what's your take?

Flags: needinfo?(jib)

AFAICT WebIDL converts -1 to an unsigned short of 63335:

  • Let x be ? ConvertToInt(V, 16, "unsigned"), which says:
    • Let lowerBound be 0. Let upperBound be 2^16 − 1.
    • Let x be ? ToNumber(V) // here -1
    • Set x to ! IntegerPart(x). // still -1
    • Set x to x modulo 2^16 // here 65535

So we just need to implement this prose:

  1. If [[DataChannelId]] is equal to 65535, which is greater than the maximum allowed ID of 65534 but still qualifies as an unsigned short, throw a TypeError.

This means, according to the spec, that -1 should TypeError, whereas e.g. -2 should not.

We could file a spec issue for stricter checking, e.g. using [EnforceRange]. That might be a good idea.

Flags: needinfo?(jib)

Wait, looks like this has already been done. RTCDataChannelInit says:

dictionary RTCDataChannelInit {
             boolean         ordered = true;
             [EnforceRange]
             unsigned short  maxPacketLifeTime;
             [EnforceRange]
             unsigned short  maxRetransmits;
             USVString       protocol = "";
             boolean         negotiated = false;
             [EnforceRange]
             unsigned short  id;
             RTCPriorityType priority = "low";
};

We just need to update our webidl to match.

This changes comment 2 to

  • If the conversion is to an IDL type associated with the [EnforceRange] extended attribute, then:
    • If x is NaN, +∞, or −∞, then throw a TypeError.
    • Set x to ! IntegerPart(x).
    • If x < lowerBound or x > upperBound, then throw a TypeError.

👍

We are also not checking for 65535 as the spec requires.

We still need to test for that manually, even after we add [EnforceRange].

I also think the -1 test should be changed to test for -2.

Alright, looks like we can fix this.

Blocks: 1533020
Assignee: nobody → docfaraday

Depends on D26769

Pushed by bcampen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/eb1553deea2f
Part 0: Re-enable some test-cases. r=jib
https://hg.mozilla.org/integration/autoland/rev/86d62da0f2a8
Part 1: webidl updates. r=jib,smaug
https://hg.mozilla.org/integration/autoland/rev/08102fb37153
Part 2: Keep up with webidl changes in part 1. r=smaug,jib
https://hg.mozilla.org/integration/autoland/rev/3e57d6dc64b2
Part 3: Fix some validation logic in createDataChannel. r=jib
https://hg.mozilla.org/integration/autoland/rev/85cc0827d8d3
Part 4: Fix some test-cases, and add some others. r=jib

The test changes here conflict with the upstream changes from https://github.com/web-platform-tests/wpt/pull/16038 and I'm not confident I can come up with the desired resolution. Can you suggest a resolved version of the two files (webrtc/RTCPeerConnection-ondatachannel.html webrtc/RTCPeerConnection-createDataChannel.html)

Flags: needinfo?(docfaraday)

Sent mail.

Flags: needinfo?(docfaraday)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: