1654211 - (CVE-2020-15678) AddressSanitizer: heap-use-after-free [@ ~BorrowedSourceSurface] with READ of size 8

Status: RESOLVED FIXED

(Core :: Graphics, defect, P1)

Description

[Christian Holler (:decoder)]

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.

Comment 1

[Christian Holler (:decoder)]

Attachment: Detailed Crash Information

Comment 3

[Brian Carpenter [:geeknik]]

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.

Comment 4

[Daniel Veditz [:dveditz]]

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.

Comment 5

[Daniel Veditz [:dveditz]]

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.

Comment 6

[Kelsey Gilbert [:jgilbert]]

Thanks, I'll look.

Comment 7

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

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

Comment 8

[Julien Cristau [:jcristau]]

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

Comment 9

[Kelsey Gilbert [:jgilbert]]

Attachment: Bug 1654211 - Hold WeakPtr to PresistentBufferProvider in BorrowedSourceSurface.

Comment 10

[Kelsey Gilbert [: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.

Comment 11

[Tom Ritter [:tjr] (OOTO until mid-August)]

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

Approved to land and uplift

Comment 12

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

https://hg.mozilla.org/integration/autoland/rev/0ec8df5bd92b7847098a2d5e1c784e7baf381a24

Comment 13

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

https://hg.mozilla.org/releases/mozilla-beta/rev/4b90dac4c40b

Comment 14

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/0ec8df5bd92b

Comment 15

[Frederik Braun [:freddy]]

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

Comment 16

[Kelsey Gilbert [: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)

Comment 17

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 18

[Kelsey Gilbert [:jgilbert]]

Survey submitted!

Comment 19

[Tom Ritter [:tjr] (OOTO until mid-August)]

Attachment: advisory.txt

Comment 20

[Tom Ritter [:tjr] (OOTO until mid-August)]

Attachment: advisory.txt

Comment 21

[Brian Carpenter [:geeknik]]

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!