Buffer overflow in sctp chunk input validation
Categories
(Core :: WebRTC: Networking, defect)
Tracking
()
People
(Reporter: drno, Assigned: drno)
References
Details
(Keywords: csectype-bounds, sec-high, Whiteboard: [reported by GPZ, disclosure date 2020-07-18][post-critsmash-triage][adv-main76+][adv-ESR68.8+])
Attachments
(3 files)
47 bytes,
text/x-phabricator-request
|
dveditz
:
approval-mozilla-beta+
RyanVM
:
approval-mozilla-esr68+
dveditz
:
sec-approval+
|
Details | Review |
47 bytes,
text/x-phabricator-request
|
dveditz
:
approval-mozilla-beta+
RyanVM
:
approval-mozilla-esr68+
dveditz
:
sec-approval+
|
Details | Review |
254 bytes,
text/plain
|
Details |
Upstream usrsctp has been notified about a buffer overflow in their implementation.
The patch for it is available upstream here https://github.com/sctplab/usrsctp/commit/e1dd9bea4f438abf4d4c3b658f1db8f013157184
Alternatively we could work around the problematic code path by disabling SCTP authentication with the following (as that feature isn't used in webrtc any way):
usrsctp_sysctl_set_sctp_asconf_enable(0);
usrsctp_sysctl_set_sctp_auth_enable(0);
Assignee | ||
Comment 1•5 years ago
|
||
Assignee | ||
Comment 2•5 years ago
|
||
Depends on D72053
Updated•5 years ago
|
Comment 3•5 years ago
|
||
Public commit doesn't literally say "SECURITY BUG!" but it does thank a prominent member of Google Project Zero. We should get a fix into 76 and ESR. Nils suggests using the the "turn it off" patch for uplift. I wouldn't mind taking both!
Comment 4•5 years ago
|
||
We're building RCs on Monday, so patches will need to be reviewed and land ASAP to make it into 76/68.8.
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 5•5 years ago
|
||
Comment on attachment 9142549 [details]
Bug 1632241: add SCTP auth token boundary check
Security Approval Request
- How easily could an exploit be constructed based on the patch?: Not very hard with knowledge on how WebRTC data channel works.
- Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: No
- Which older supported branches are affected by this flaw?: all
- If not all supported branches, which bug introduced the flaw?: None
- Do you have backports for the affected branches?: Yes
- If not, how different, hard to create, and risky will they be?:
- How likely is this patch to cause regressions; how much testing does it need?: Not very likely as the affected code paths normally should not be triggered by normal WebRTC endpoints.
Assignee | ||
Updated•5 years ago
|
Updated•5 years ago
|
Comment 6•5 years ago
|
||
Comment on attachment 9142549 [details]
Bug 1632241: add SCTP auth token boundary check
sec-approval+ and a=dveditz for beta uplift.
Comment 7•5 years ago
|
||
Comment 8•5 years ago
|
||
uplift |
![]() |
||
Comment 9•5 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/b277e280752e
https://hg.mozilla.org/mozilla-central/rev/685b68485248
Assignee | ||
Comment 10•5 years ago
|
||
Comment on attachment 9142549 [details]
Bug 1632241: add SCTP auth token boundary check
ESR Uplift Approval Request
- If this is not a sec:{high,crit} bug, please state case for ESR consideration: It is sec-high
- User impact if declined: Users would be exposed to the technically possible drive-by buffer overflow.
- Fix Landed on Version: 76
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): The risk is low, because the buffer overflow is on a code path which is normally not used in WebRTC. That means only a specifically crafted PeerConnection endpoints which sends packets which are normally not send as part of WebRTC connection could trigger this.
- String or UUID changes made by this patch: N/A
Assignee | ||
Updated•5 years ago
|
Comment 11•5 years ago
|
||
Comment on attachment 9142549 [details]
Bug 1632241: add SCTP auth token boundary check
Approved for 68.8esr.
Updated•5 years ago
|
Comment 12•5 years ago
|
||
uplift |
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 13•5 years ago
|
||
Updated•5 years ago
|
Comment 14•5 years ago
|
||
Looks like Chrome is going to ship this fix in an update to their current Stable 81 soon and not wait for 83 (there was no 82)
Comment 15•5 years ago
|
||
Chatted with adetaylor on the Chrome security team and we'll assign CVE-2020-6831 to this SCTP bug.
Updated•5 years ago
|
Description
•