Closed Bug 817432 Opened 10 years ago Closed 10 years ago

Use correct ICE ufrag/passwords.


(Core :: WebRTC: Networking, defect)

Not set



Tracking Status
firefox17 --- unaffected
firefox18 - disabled
firefox19 - unaffected
firefox20 + fixed
firefox-esr10 --- unaffected
firefox-esr17 --- unaffected
b2g18 --- unaffected


(Reporter: ekr, Assigned: abr)


(Keywords: sec-moderate, Whiteboard: [WebRTC],[blocking-webrtc-interop],[nICEr],[blocking-webrtc+][qa-][adv-main20-])


(1 file)

The current ufrag/passwords appear to be inverted. At least they are inverted from what chrom e uses.

Please check against RFC 5245 and if this patch is correct, then clean and land.

Please coordinate landing this patch with an uplift to nICEr on
Why is this a security-sensitive issue?
Assignee: nobody → adam
The usernames and passwords are intended to prevent attackers from forging ICE responses. Using the wrong ones potentially changes those properties, so until this is analyzed it should be treated as sensitive
Whiteboard: [WebRTC],[blocking-webrtc-interop]
By my reading, the proposed patch appears to match the behavior described in RFC 5245, section
Attachment #687557 - Flags: review?(rjesup)
Whiteboard: [WebRTC],[blocking-webrtc-interop] → [WebRTC],[blocking-webrtc-interop],[nICEr]
Attachment #687557 - Flags: review?(rjesup) → review+
Comment on attachment 687557 [details] [diff] [review]
Fix ICE username/passwords order

[Security approval request comment]
> How easily can the security issue be deduced from the patch?

It is very easy to tell that the username order was backwards by reading the patch.

> Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?

No -- any means of exploiting this bug would be quite subtle, and would likely take the form of tricking Firefox into sending RTP traffic to a destination that did not desire such traffic.

> Which older supported branches are affected by this flaw?

FF 18 and 19 contain this code. However, this code is only executed as part of WebRTC handling. WebRTC is preffed off by default in these builds, so exposure in 18 and 19 is very limited.

> If not all supported branches, which bug introduced the flaw?

> Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?

The source file in question does not appear to have been changed since its introduction. The patch should apply cleanly to all branches.

> How likely is this patch to cause regressions; how much testing does it need?

Previously, the only implementations Mozilla's WebRTC would work with was itself. Reversing these fields to their correct order allows interoperation with Chrome; however, any Firefox with this fix applied will be unable to interoperate with earlier versions that do not have this patch. There is no obvious way to work around this shortcoming.
Attachment #687557 - Flags: sec-approval?
Attachment #687557 - Flags: sec-approval? → sec-approval+
sec-approval+ for trunk.

CC'ing Release Management so they can determine whether they want this in 18 or 19.
Given where we are in the cycle, we'll avoid unnecessary change for pref'd off features.
Attachment #687557 - Flags: checkin?(rjesup)
Attachment #687557 - Flags: checkin?(rjesup) → checkin+
Whiteboard: [WebRTC],[blocking-webrtc-interop],[nICEr] → [WebRTC],[blocking-webrtc-interop],[nICEr],[blocking-webrtc+]
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [WebRTC],[blocking-webrtc-interop],[nICEr],[blocking-webrtc+] → [WebRTC],[blocking-webrtc-interop],[nICEr],[blocking-webrtc+][qa-]
Whiteboard: [WebRTC],[blocking-webrtc-interop],[nICEr],[blocking-webrtc+][qa-] → [WebRTC],[blocking-webrtc-interop],[nICEr],[blocking-webrtc+][qa-][adv-main20-]
Group: core-security
You need to log in before you can comment on or make changes to this bug.