817432 - Use correct ICE ufrag/passwords.

Status: RESOLVED FIXED

(Core :: WebRTC: Networking, defect)

Description

[Eric Rescorla (:ekr)]

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 resiprocate.org

Comment 1

[Eric Rescorla (:ekr)]

Attachment: Fix ICE username/passwords order

Comment 2

[Reed Loden [:reed]]

Why is this a security-sensitive issue?

Comment 3

[Eric Rescorla (:ekr)]

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

Comment 4

[Adam Roach [:abr]]

By my reading, the proposed patch appears to match the behavior described in RFC 5245, section 7.1.2.3.

Comment 5

[Adam Roach [:abr]]

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?

https://bugzilla.mozilla.org/show_bug.cgi?id=790517

> 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.

Comment 6

[Al Billings [:abillings - ex-MoCo]]

sec-approval+ for trunk.

CC'ing Release Management so they can determine whether they want this in 18 or 19.

Comment 7

[Alex Keybl [:akeybl]]

Given where we are in the cycle, we'll avoid unnecessary change for pref'd off features.

Comment 8

[Randell Jesup [:jesup] (needinfo me)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/7963fe83e7a2

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/7963fe83e7a2

Comment 10

[Adam Roach [:abr]]

Landed on resiprocate trunk r9911: http://svn.resiprocate.org/viewsvn/resiprocate?diff_format=l&view=revision&revision=9911