Closed Bug 1683964 (CVE-2020-16044) Opened 6 months ago Closed 5 months ago

Use-after-free write when handling malicious COOKIE-ECHO

Categories

(Core :: WebRTC: Networking, defect, P1)

defect

Tracking

()

RESOLVED FIXED
Tracking Status
firefox-esr78 84+ fixed
firefox84 + fixed
firefox85 + fixed
firefox86 + fixed

People

(Reporter: mccr8, Assigned: drno, NeedInfo)

References

()

Details

(Keywords: csectype-uaf, sec-critical, Whiteboard: [sec-survey])

Attachments

(3 files)

I don't know if this applies to Firefox or not, but Project Zero just opened up a bug containing a use-after-free in SCTP: https://bugs.chromium.org/p/project-zero/issues/detail?id=2094

The commit said to fix it is here: https://github.com/sctplab/usrsctp/commit/d844a690d30ace22de75e8b80d9bb08ae7283795

I didn't check the whole patch, but our code in netwerk/sctp/src/netinet/sctp_input.c at least appears to match the pre-patch state, and neither that file nor netwerk/sctp/src/netinet/sctp_pcb.c have changed since July.

(the bug summary I used just comes from the Project Zero report)

I guess the patch in comment 0 has been public since September, for what it is worth.

Flags: needinfo?(rjesup)
Flags: needinfo?(rjesup)

Oops, didn't mean to do that needinfo.

It looks like Chrome is not shipping this fix either. tjr found this history log where they apparently landed it as part of a large patch rollup, but backed it out because something in there was causing issues: https://chromium.googlesource.com/chromium/src/+log/HEAD/third_party/usrsctp (this page takes a while to load)

(In reply to Andrew McCreight [:mccr8] from comment #4)

It looks like Chrome is not shipping this fix either. tjr found this history log where they apparently landed it as part of a large patch rollup, but backed it out because something in there was causing issues: https://chromium.googlesource.com/chromium/src/+log/HEAD/third_party/usrsctp (this page takes a while to load)

Yes in https://bugs.chromium.org/p/chromium/issues/detail?id=1157658 they reverted a big rollup patch which included the security fix, because Chrome had picked up changes in libusrsctp which was trying to use getrandom() without checking for it's availability.
Our version of libusrsctp does appear to have any calls to getrandom() in it yet. So I assume it should be save to cherry pick just the security fix.

Assignee: nobody → drno
Severity: -- → S1
Priority: -- → P1

Rating this -critical because P0 has publicly disclosed the bug and they get a lot of attention. But Chrome hasn't shipped the fix yet; which is odd.

Keywords: sec-critical

Turns out that https://github.com/sctplab/usrsctp/commit/d844a690d30ace22de75e8b80d9bb08ae7283795?branch=d844a690d30ace22de75e8b80d9bb08ae7283795&diff=split was only a part of series of problems P0 found in how usrsctp handles cookies.
The usrsctp maintainers recommended to take these two patches as well:
https://github.com/sctplab/usrsctp/commit/355fb576b1a9dfef70fc0e158d66692662baaddc
https://github.com/sctplab/usrsctp/commit/7dab23aa0d8db86fedd222a308067439b03fad0f

I'll add them to the patch shortly.

Depends on D100490

Comment on attachment 9194513 [details]
Bug 1683964: Improve the input validation and processing of sctp cookies.

pre-emptively sec-approving these, they are already public in several ways.

Attachment #9194513 - Flags: sec-approval+

Comment on attachment 9194766 [details]
Bug 1683964: clean up more resources of existing SCTP association in case of a restart.

pre-emptively sec-approving these, they are already public in several ways.

Attachment #9194766 - Flags: sec-approval+

Comment on attachment 9194767 [details]
Bug 1683964: Harden the handling of outgoing streams.

pre-emptively sec-approving these, they are already public in several ways.

Attachment #9194767 - Flags: sec-approval+

Comment on attachment 9194513 [details]
Bug 1683964: Improve the input validation and processing of sctp cookies.

Security Approval Request (just for the record):

  • How easily could an exploit be constructed based on the patch?: Patches are already publicly available upstream. Probably requires SCTP protocol expertise to figure out how to abuse it.
  • Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: No (but the patches have landed upstream in public already).
  • 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?: I'm not really certain about this. These changes are deep in the SCTP protocol levels and could cause problems. But they have been reviewed and merged upstream, and are not known for causing any problems so far.

Please request uplift to beta, release and esr78.

Flags: needinfo?(drno)

Comment on attachment 9194513 [details]
Bug 1683964: Improve the input validation and processing of sctp cookies.

Beta/Release Uplift Approval Request

  • User impact if declined: Attacker can potentially break the SCTP cookie and create a use after free in Firefox.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Patches have been merged upstream for several weeks now with no issues reported so far.
  • String changes made/needed: N/A
Flags: needinfo?(drno)
Attachment #9194513 - Flags: approval-mozilla-beta?
Attachment #9194766 - Flags: approval-mozilla-beta?
Attachment #9194767 - Flags: approval-mozilla-beta?

Comment on attachment 9194513 [details]
Bug 1683964: Improve the input validation and processing of sctp cookies.

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: sec-crit
  • User impact if declined: Attacker can potentially break the SCTP cookie and create a use after free in Firefox.
  • Fix Landed on Version: 86
  • Risk to taking this patch: Medium
  • Why is the change risky/not risky? (and alternatives if risky): Patches have been merged upstream for several weeks now with no issues reported so far.
  • String or UUID changes made by this patch: N/A
Attachment #9194513 - Flags: approval-mozilla-esr78?
Attachment #9194766 - Flags: approval-mozilla-esr78?
Attachment #9194767 - Flags: approval-mozilla-esr78?

Comment on attachment 9194513 [details]
Bug 1683964: Improve the input validation and processing of sctp cookies.

Approved for 85.0b5, 84.0.2, and 78.6.1esr. And Fenix 84.1.3 and Focus 8.11.3.

Attachment #9194513 - Flags: approval-mozilla-release+
Attachment #9194513 - Flags: approval-mozilla-esr78?
Attachment #9194513 - Flags: approval-mozilla-esr78+
Attachment #9194513 - Flags: approval-mozilla-beta?
Attachment #9194513 - Flags: approval-mozilla-beta+
Attachment #9194766 - Flags: approval-mozilla-release+
Attachment #9194766 - Flags: approval-mozilla-esr78?
Attachment #9194766 - Flags: approval-mozilla-esr78+
Attachment #9194766 - Flags: approval-mozilla-beta?
Attachment #9194766 - Flags: approval-mozilla-beta+
Attachment #9194767 - Flags: approval-mozilla-release+
Attachment #9194767 - Flags: approval-mozilla-esr78?
Attachment #9194767 - Flags: approval-mozilla-esr78+
Attachment #9194767 - Flags: approval-mozilla-beta?
Attachment #9194767 - Flags: approval-mozilla-beta+

As part of a security bug pattern analysis, we are requesting your help with a high level analysis of this bug. It is our hope to develop static analysis (or potentially runtime/dynamic analysis) in the future to identify classes of bugs.

Please visit this google form to reply.

Flags: needinfo?(drno)
Whiteboard: [sec-survey]
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.