1637112 - (CVE-2020-12407) 'border-image' rendering is broken in WebRender

Status: VERIFIED FIXED

(Core :: Graphics: WebRender, defect)

Description

[Mats Palmgren (inactive)]

Attachment: Testcase

The test works correctly in Firefox v76 and Chrome v81.

Comment 1

[Mats Palmgren (inactive)]

Attachment: Screenshot

Is the top border segment of the first box rendering random memory?

Comment 2

[Emilio Cobos Álvarez (:emilio)]

I see it broken in 75 as well. Probably WebRender specific?

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: another screenshot :-(

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Yeah, it's a WebRender bug looks like. And yeah, it's GPU memory, I got some text from my terminal there :)

Comment 5

[Emilio Cobos Álvarez (:emilio)]

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=22c3548439448650935700df5a7b813e2f537f3f&tochange=ee4b15857843597bc408305c170ff30a02ede1cc

Comment 6

[Mats Palmgren (inactive)]

Hmm, this seems like a security issue then.

Comment 7

[Nicolas Silva [:nical]]

Attachment: Bug 1637112 - Don't draw border-image segments with zero slice size. r=mstange

Comment 8

[Nicolas Silva [:nical]]

I would be surprised if this is exploitable but the fix is simple enough that it is a good candidate for uplift.

Comment 9

[Ryan VanderMeulen [:RyanVM]]

Can we land a test for this?

Comment 10

[Nicolas Silva [:nical]]

Yeah I'll add a reftest. I wasn't sure the behavior was what the spec intended.

Comment 11

[Nicolas Silva [:nical]]

Attachment: Bug 1637112 - Add a wrench reftest. r=mstange.

Comment 12

[Daniel Veditz [:dveditz]]

Can a web page get images back out of WebRender? Like, the leaked data is on the screen, but not on something like a <canvas> that could be read back? Would it be captured by a screenshot?

Comment 13

[Nicolas Silva [:nical]]

Web pages aren't allowed to read pixels back from webrender. In gecko we have two ways to do screenshots, one that reads webrender's framebuffers (what the gecko profiler uses) and one that reconstructs the page on the content process and draws it without webrender (drawWindow which extensions can ask access to, but that's not affected by webrender). Both are privileged APIs that web pages don't have access to as far as I know.
I think webrtc has a screen sharing feature, which I expect can see the output of webrender, but that requires pretty verbose permission requests.

Beyond that I believe that it's quite hard to craft getting the texture cache's pieces of uninitialized memory to land on anything interesting. You are more likely to land on other bits of content of the same page which, if you get to that point, you already have access to.

Comment 14

[Mats Palmgren (inactive)]

(In reply to Nicolas Silva [:nical] from comment #13)

Beyond that I believe that it's quite hard to craft getting the texture cache's pieces of uninitialized memory to land on anything interesting. You are more likely to land on other bits of content of the same page which, if you get to that point, you already have access to.

It's actually quite easy for me to see interesting content from other processes. If I start a separate browser and load a video into it I often get a region of that video into the border and not just a single frame - it's a slice of the live running video stream!

Also, many programs off-load more than just rendering to the GPU these days so if we can somehow write to their GPU memory here then it might be more problematic.

Comment 15

[Nicolas Silva [:nical]]

My understanding is that we are reading uninitialized parts of a texture here. There is a strict separation between what shaders can read and write, and it would require a pretty catastrophic driver bug to be able to write into another program's active gpu memory.
It would take a security exploit for a page to be able to read webrender's gpu memory, so I am not overly worried. It doesn't hurt to treat this as a security issue anyway.

it's a slice of the live running video stream!

That's pretty wild, I wonder if this can be reproduced with webgl.

Comment 16

[Nicolas Silva [:nical]]

Comment on attachment 9148030 [details]
Bug 1637112 - Don't draw border-image segments with zero slice size. r=mstange

Security Approval Request

• How easily could an exploit be constructed based on the patch?: I don't think it can without another exploit, so hard. But if an attacker manages to read back webrender's memory, then this could let them read random things from other process's gpu memory.
• 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?: it should apply cleanly to older branches.
• How likely is this patch to cause regressions; how much testing does it need?: Not very likely, let's let it bake on nightly for a few days and uplift after that.

Comment 17

[Daniel Veditz [:dveditz]]

Which older supported branches are affected by this flaw?: all

I'm having trouble reconciling that answer with others earlier saying ESR-68 is unaffected. Do we need this fixed on ESR or not?

Comment 18

[Nicolas Silva [:nical]]

My bad. The bug exists in all branches but it will not cause NaN texture coordinates in esr 68 which is the cause of the rendered garbage here. It does in Release, though.

Comment 19

[Ryan VanderMeulen [:RyanVM]]

WebRender is also disabled on ESR. Unless there's also a non-WR variant of this issue as well?

Comment 20

[Nicolas Silva [:nical]]

This is webrender-only.

Comment 21

[Daniel Veditz [:dveditz]]

Comment on attachment 9148030 [details]
Bug 1637112 - Don't draw border-image segments with zero slice size. r=mstange

sec-approval+, a=dveditz for beta

Comment 22

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/autoland/rev/b57a096b5ba4955abe131079820801457ee397af
https://hg.mozilla.org/integration/autoland/rev/67745f2dd84827d30f654d75766351ff788f5114

https://hg.mozilla.org/releases/mozilla-beta/rev/1f441180b014
https://hg.mozilla.org/releases/mozilla-beta/rev/d50a69ba1ac4

Comment 23

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

https://hg.mozilla.org/mozilla-central/rev/b57a096b5ba4
https://hg.mozilla.org/mozilla-central/rev/67745f2dd848

Comment 24

[Brindusa Tot, Desktop QA]

Reproduced the issue on Windows 10 and Ubuntu 18, with Nightly 78.0a1, Build ID 20200518093924.

Verified as fixed on Ubuntu 18, Windows 10 x64 and MacOS 10.14.6, with

• Latest Nightly 78.0a1, Build Id 20200525093440
• Latest Beta 77.0b9, Build ID 20200521224544.

Comment 25

[Frederik Braun [:freddy]]

Attachment: advisory.txt