Closed Bug 1632241 (CVE-2020-6831) Opened 1 year ago Closed 1 year ago

Buffer overflow in sctp chunk input validation

Categories

(Core :: WebRTC: Networking, defect)

defect

Tracking

()

RESOLVED FIXED
mozilla77
Tracking Status
firefox-esr68 76+ fixed
firefox75 --- wontfix
firefox76 + fixed
firefox77 + fixed

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)

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);

Group: core-security → media-core-security
Whiteboard: [reported by GPZ, unknown disclosure date]

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!

We're building RCs on Monday, so patches will need to be reviewed and land ASAP to make it into 76/68.8.

Assignee: nobody → drno
Status: NEW → ASSIGNED
Whiteboard: [reported by GPZ, unknown disclosure date] → [reported by GPZ, disclosure date 2020-07-18]

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.
Attachment #9142549 - Flags: sec-approval?
Attachment #9142556 - Flags: sec-approval?
Attachment #9142556 - Flags: sec-approval?
Attachment #9142556 - Flags: sec-approval+
Attachment #9142556 - Flags: approval-mozilla-beta+

Comment on attachment 9142549 [details]
Bug 1632241: add SCTP auth token boundary check

sec-approval+ and a=dveditz for beta uplift.

Attachment #9142549 - Flags: sec-approval?
Attachment #9142549 - Flags: sec-approval+
Attachment #9142549 - Flags: approval-mozilla-beta+
Group: media-core-security → core-security-release
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla77

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
Attachment #9142549 - Flags: approval-mozilla-esr68?
Attachment #9142556 - Flags: approval-mozilla-esr68?

Comment on attachment 9142549 [details]
Bug 1632241: add SCTP auth token boundary check

Approved for 68.8esr.

Attachment #9142549 - Flags: approval-mozilla-esr68? → approval-mozilla-esr68+
Attachment #9142556 - Flags: approval-mozilla-esr68? → approval-mozilla-esr68+
Flags: qe-verify-
Whiteboard: [reported by GPZ, disclosure date 2020-07-18] → [reported by GPZ, disclosure date 2020-07-18][post-critsmash-triage]
Whiteboard: [reported by GPZ, disclosure date 2020-07-18][post-critsmash-triage] → [reported by GPZ, disclosure date 2020-07-18][post-critsmash-triage][adv-main76+]
Whiteboard: [reported by GPZ, disclosure date 2020-07-18][post-critsmash-triage][adv-main76+] → [reported by GPZ, disclosure date 2020-07-18][post-critsmash-triage][adv-main76+][adv-ESR68.8+r]
Whiteboard: [reported by GPZ, disclosure date 2020-07-18][post-critsmash-triage][adv-main76+][adv-ESR68.8+r] → [reported by GPZ, disclosure date 2020-07-18][post-critsmash-triage][adv-main76+][adv-ESR68.8+]

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)

Chatted with adetaylor on the Chrome security team and we'll assign CVE-2020-6831 to this SCTP bug.

Alias: CVE-2020-6831
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.