1700235 - (CVE-2021-29961) <select> element with large size then transformed with scale() allow WebRender to render over Firefox UI

Status: VERIFIED FIXED

(Core :: Graphics: WebRender, defect)

Description

[Irvan Kurniawan (:sourc7)]

Attachment: drawbar.bundle.html

When create <select> element with large size attribute and large font-size, then transform the element with CSS scale(), the element is rendered and stretched over Firefox toolbar and other UI.

mozregression show the regression range is started from commit Bug 1664719 - Pt 2a - Re-enable is_ancestor check:

19:51.48 INFO: Narrowed integration regression window from [b88d1d84, c8102686] (3 builds) to [25a50264, c8102686] (2 builds) (~1 steps left)
19:51.48 INFO: No more integration revisions, bisection finished.
19:51.48 INFO: Last good revision: 25a50264ae3204f2df9add308fc712df45947637
19:51.48 INFO: First bad revision: c8102686489e51edec8a976f013398412577be44
19:51.48 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=25a50264ae3204f2df9add308fc712df45947637&tochange=c8102686489e51edec8a976f013398412577be44

As it able to render over Firefox address bar and toolbar UI, I can assume it's possible to spoof the address bar with background-image or hide the address bar with background-color.

Reproduced on:

• Firefox Nightly 88.0a1 (2021-03-22) (64-bit) on Arch Linux (AMD RENOIR (DRM 3.40.0, 5.11.6-arch1-1, LLVM 11.1.0)
• Firefox Nightly 88.0a1 (2021-03-22) (64-bit) on Windows 10 (AMD A8-7410 R5 Graphics)
• Firefox Nightly 88.0a1 (2021-03-22) (64-bit) on Windows 10 (Intel i5-1035G1)

Steps to Reproduce:

1. Open Firefox with WebRender enabled
2. Visit attached drawbar.bundle.html or hidebar.bundle.html
3. The toolbar is now covered by background-image or background-color

(If toolbar is only partially covered on your screen, try to zoom-in or zoom-out the page, or increase the CSS scale() or <select> size)

Comment 1

[Irvan Kurniawan (:sourc7)]

Attachment: hidebar.bundle.html

Comment 2

[Irvan Kurniawan (:sourc7)]

Attachment: Firefox WebRender Render over UI - Drawbar - Intel i5-1035G1.mp4

Comment 3

[Irvan Kurniawan (:sourc7)]

Attachment: Firefox Webrender Render over UI - Drawbar (Reduced Scale) - Intel i5-1035G1.mp4

Comment 4

[Irvan Kurniawan (:sourc7)]

Attachment: Firefox WebRender Render over UI - Hidebar - Intel i5-1035G1.mp4

Comment 5

[Glenn Watson [:gw]]

I can't reproduce drawing over the titlebar after trying a number of zoom / scale / resolution configurations. But it does draw what looks like garbage at the bottom of the screen for me. I'll investigate that and find what's happening - hopefully whatever causes that is the same issue.

Comment 6

[Glenn Watson [:gw]]

I was able to reduce the case further and reproduce in a wrench capture.

The problem is caused by (a lack of) f32 accuracy.

From Gecko, the display list contains a spatial node with transform ([1.0, 0.0, 0.0, 0.0, 0.0, 300.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, -652528960.0, 0.0, 1.0]).

Since the coordinate system for that is axis-aligned with respect to the global iframe clip rect, WR maps the iframe clip-rect into this primitive's coordinate space, and intersects with the primitive's local clip rect, providing a single local clip rect that is applied during vertex shading.

However, the extremely large offset combined with the very large y-scale in the transform means that floating point accuracy loss occurs, and the mapped clip rect is incorrectly now referencing an area outside the iframe clip in world space by ~47 pixels in my local test case.

How would such a case be handled in non-WR Gecko? Does Gecko layout / DL building do any rejection or clamping of extremely large transforms like this?

Comment 7

[Emilio Cobos Álvarez (:emilio)]

I don't know this off the top of my head, but if Matt / Jeff can't answer let me know and I can dig.

Comment 8

[Jeff Muizelaar [:jrmuizel]]

Clipping is mostly done in device space (often with fixed point) so there's no opportunity for floating point error to cause a problem.

Comment 9

[Glenn Watson [:gw]]

Thinking about this more overnight - it's still unclear to me why the overall content frame clip doesn't end up being applied to the content tiles. I need to investigate that, as that seems like the simplest way to ensure this can't happen.

Comment 10

[Glenn Watson [:gw]]

The partial answer to the question in comment 8 is that for the picture cache tiles that overlap with the URL bar, there is no clip rect on the picture cache instance constraining them to the content region. Next step is to work out why this is.

Comment 11

[Glenn Watson [:gw]]

Attachment: Bug 1700235 - Apply iframe clips on tile caches instead of prims.

Comment 12

[Glenn Watson [:gw]]

The attached patch provides a solution that prevents the floating point inaccuracy affecting outside a content iframe, by ensuring that iframe clip rects are applied to the picture cache tiles (which aren't affected by the floating point accuracy issues in the content).

In some ways this is a band-aid fix, in that the float inaccuracy can still cause rendering artifacts within content, but it should prevent content leaking outside the iframe clip in these cases. We can work on the content inaccuracy with extreme transforms and primitive sizes as a lower priority.

Comment 13

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

Apply iframe clips on tile caches instead of prims. r=nical,kvark
https://hg.mozilla.org/integration/autoland/rev/8a4eff9d5f949a52dd7097395f4a124ceb9e39d4
https://hg.mozilla.org/mozilla-central/rev/8a4eff9d5f94

Comment 14

[Ryan VanderMeulen [:RyanVM]]

Backed out from Beta to avoid shipping 89.0b1 with the various regressions being filed off it. We can consider re-landing it once those are resolved on Nightly.
https://hg.mozilla.org/releases/mozilla-beta/rev/2cd99c728148493e0ee78c765d53a4ca40638c61

Comment 15

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

Backed out for painting regressions:

https://hg.mozilla.org/mozilla-central/rev/09bea3dd34bd0da18d56758701528ca7be22c0ea

Comment 16

[Glenn Watson [:gw]]

Attachment: Bug 1700235 - Apply iframe clips on tile caches instead of prims.

Comment 17

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

Apply iframe clips on tile caches instead of prims. r=gfx-reviewers,kvark
https://hg.mozilla.org/integration/autoland/rev/6527552f2b2809528c69db127d813bf0a065d44c
https://hg.mozilla.org/mozilla-central/rev/6527552f2b28

Comment 18

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

The patch landed in nightly and beta is affected.
:gw, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.
If yes, don't forget to request an uplift for the patches in the regressions caused by this fix.

For more information, please visit auto_nag documentation.

Comment 19

[Julien Cristau [:jcristau]]

redirecting to :kvark given Glenn's PTO

Comment 20

[Dzmitry Malyshau [:kvark]]

Comment on attachment 9217049 [details]
Bug 1700235 - Apply iframe clips on tile caches instead of prims.

Beta/Release Uplift Approval Request

• User impact if declined: Potential security risk of malicious pages rendering over UI and luring the user to click on stuff they don't want to.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Copied from the first comment:

• Open Firefox with WebRender enabled
• Visit attached drawbar.bundle.html or hidebar.bundle.html
• The toolbar is now covered by background-image or background-color

(If toolbar is only partially covered on your screen, try to zoom-in or zoom-out the page, or increase the CSS scale() or <select> size)

• List of other uplifts needed: None
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): It's not entirely trivial, and it didn't get much of the testing in Nightly yet.
• String changes made/needed:

Comment 21

[Dzmitry Malyshau [:kvark]]

Requesting uplift

Comment 22

[Alexandru Trif, Desktop QA [:atrif]]

Attachment: image

Hello! Using the attached TC's saved locally and STR from comment 20 I managed to reproduce the issue with Firefox 88.0a1 (20210302134918) on Windows 10x64 as follows:

1. opening drawbar.bundle.html displayed the toolbar and address bar covered by a background-image
2. opening Set title with the name from hidebar.bundle.html and set title with URL opened a new window without the address bar displayed.

Using Firefox 90.0a1 (20210429092605) on Windows 10x64, macOS 10.12, and Ubuntu 20.04:

1. clicking both options from hidebar.bundle.html opens a new window with address bar displayed
2. opening drawbar.bundle.html no longer displays background-image on the address bar and tab bar but it displayed underneath when zooming in/out.

Attached a screenshot with all results. Are these expected? Thank you in advance!

Comment 23

[Dzmitry Malyshau [:kvark]]

Thank you, Alexandru!
Given your observations, as well as the newly found regression, it's a tough call to make.
I think, given that the change still fixes the case of overlapping UI contents, it would be good to land in Beta. The security fix is more important than the drawbacks here.

Comment 24

[Glenn Watson [:gw]]

Hi Alexandru,

Thanks for verifying - yes, those results appear to be as expected.

It's OK that we get some weird looking content inside the content frame for this test case (it involves extreme scale / stretching of a large image), so long as it doesn't draw on the main UI itself.

I'll investigate the attached regression today - if we can solve that easily, it's probably fine to uplift this.

Comment 25

[Alexandru Trif, Desktop QA [:atrif]]

Thank you both for all the information! marking 90 as verified per the above comments.

Comment 26

[Pascal Chevrel:pascalc (PTO until April 26)]

Comment on attachment 9217049 [details]
Bug 1700235 - Apply iframe clips on tile caches instead of prims.

Approved for 89 beta 10, thanks.

Comment 27

[Pascal Chevrel:pascalc (PTO until April 26)]

https://hg.mozilla.org/releases/mozilla-beta/rev/361beb8a5622

Comment 28

[Alexandru Trif, Desktop QA [:atrif]]

Verified fixed with 89.0b10 (20210509185840) on Windows10x64, macOS 11 and Ubuntu 18.04. The same results are displayed as in comment 22.

Comment 29

[Frederik Braun [:freddy]]

Attachment: advisory.txt