Closed Bug 1654211 (CVE-2020-15678) Opened 11 months ago Closed 10 months ago

AddressSanitizer: heap-use-after-free [@ ~BorrowedSourceSurface] with READ of size 8

Categories

(Core :: Graphics, defect, P1)

x86_64
Linux
defect

Tracking

()

RESOLVED FIXED
82 Branch
Tracking Status
firefox-esr68 --- unaffected
firefox-esr78 --- unaffected
firefox78 --- unaffected
firefox79 + wontfix
firefox80 + wontfix
firefox81 + fixed
firefox82 + fixed

People

(Reporter: decoder, Assigned: jgilbert)

References

(Regression)

Details

(4 keywords, Whiteboard: [sec-survey][post-critsmash-triage][adv-main81+])

Crash Data

Attachments

(3 files, 1 obsolete file)

The attached crash information was submitted via the ASan Nightly Reporter on mozilla-central-asan-nightly revision 80.0a1-20200719090414-https://hg.mozilla.org/mozilla-central/rev/e785ebabf7e142898e31a6c81a4d43d44eff39e3.

For detailed crash information, see attachment.

Flags: sec-bounty?

This was discovered on Fedora 31, this box has an Nvidia RTX 2070 with the official 440.100 drivers. Window manager is xfce4. The following extra configuration options are set if it makes a difference:

gfx.webrender.all = true
fission.autostart = true
image.avif.enabled = true

No other information to share as this seems to have been found while randomly browsing the web. If I can trigger this again, I'll keep notes.

Group: core-security → gfx-core-security

This crash appears to be in code added in a WebGL refactor for out-of-process (bug 1632249), so that puts a lower limit on affected versions at 79, though this could be a more recent regression. mReturnTo is a raw pointer so apparently the borrowed surface is outliving the "persistent" buffer somehow.

Flags: needinfo?(jgilbert)

Crashes start in the 20200611093454 build which would be consistent to when bug 1632249 was checked in. bug 1646408 was filed on the regressing signature but not tagged as a security bug. Although Linux crashes look like null derefs, Windows ones are clearly UAF -- rax is 0xe5e5e5e5e5e5e5e5. for example bp-e922e421-30e8-49dc-9a5a-ee5230200703

[Tracking Requested - why for this release]:
I'm sure this is way too late for 79--haven't even started looking at a fix--but wanted to flag it for visibility since it's a security regression in that release.

Crash Signature: [@ mozilla::layers::BorrowedSourceSurface::~BorrowedSourceSurface ]
See Also: → 1646408
Regressed by: 1632249

Thanks, I'll look.

Flags: needinfo?(jgilbert)
Assignee: nobody → jgilbert
Severity: critical → S2
Priority: -- → P1

tracking+ for 79, but yeah, probably too late to get it fixed except maaaaybe in a dot release :(

Any updates Jeff? We're about to build the last beta for 80.

Flags: needinfo?(jgilbert)

Comment on attachment 9171792 [details]
Bug 1654211 - Hold WeakPtr to PresistentBufferProvider in BorrowedSourceSurface.

Security Approval Request

  • How easily could an exploit be constructed based on the patch?: Hard: An attacker would need to construct a situation that replaced the PresistentBufferProvider's memory with something else, such that this call to PresistentBufferProvider->ReturnSnapshot(surf) causes an issue.
  • 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?: 79+
  • If not all supported branches, which bug introduced the flaw?: Bug 1632249
  • Do you have backports for the affected branches?: Yes
  • If not, how different, hard to create, and risky will they be?: Should be trivial.
  • How likely is this patch to cause regressions; how much testing does it need?: Low chance for regressions for this very targeted fix.
Flags: needinfo?(jgilbert)
Attachment #9171792 - Flags: sec-approval?

Comment on attachment 9171792 [details]
Bug 1654211 - Hold WeakPtr to PresistentBufferProvider in BorrowedSourceSurface.

Approved to land and uplift

Attachment #9171792 - Flags: sec-approval?
Attachment #9171792 - Flags: sec-approval+
Attachment #9171792 - Flags: approval-mozilla-beta+
Group: gfx-core-security → core-security-release
Status: NEW → RESOLVED
Closed: 10 months ago
Resolution: --- → FIXED
Target Milestone: --- → 82 Branch
Flags: sec-bounty? → sec-bounty+

Jeff, can we resolve bug 1646408 with this one fixed?

Flags: needinfo?(jgilbert)

(In reply to Frederik Braun [:freddy] from comment #15)

Jeff, can we resolve bug 1646408 with this one fixed?

Yes, but how and when? (given that this is a sec bug not fixed in all versions)

Flags: needinfo?(jgilbert) → needinfo?(fbraun)

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?(jgilbert)
Whiteboard: [sec-survey]

Survey submitted!

Flags: needinfo?(jgilbert)
Regressions: 1664257
Flags: qe-verify-
Whiteboard: [sec-survey] → [sec-survey][post-critsmash-triage]
Whiteboard: [sec-survey][post-critsmash-triage] → [sec-survey][post-critsmash-triage][adv-main81+]
Flags: needinfo?(fbraun)

Can you update the alias of this bug to CVE-2020-15675 and update the alias of bug 1660211 to CVE-2020-15678? I think they got flipped around. Thanks!

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