1814597 - (CVE-2023-29533) Multiple requestFullScreen repeatedly then launch window with same window name able to overlap fullscreen notification toast

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect, P2)

Description

[Irvan Kurniawan (:sourc7)]

Attachment: testcase.html

After launch new popup window then repeatedly call multiple requestFullscreen using setInterval and launch popup window with same windowName interestingly it able to overlap fullscreen notification toast.

I have tested this works on Linux X11 and Wayland.

Tested on:

• Firefox Nightly 111.0a1 (2023-02-01) (64-bit) on Arch Linux KDE and Ubuntu 22.10
• Firefox 109.0.1 (64-bit) on Arch Linux KDE

Steps to reproduce

1. Visit attached testcase.html
2. Click "newWindow" button
3. Click "Spoof" button on Main Window
4. Re-click "Spoof" if child window not maximized or browser not goes into full-screen
5. Browser goes into full-screen and overlapped by popup window

Comment 1

[Irvan Kurniawan (:sourc7)]

Attachment: Firefox - Multiple requestFullscreen repeatedly + reuse popup window name able to overlap fullscreen toast.mp4

Comment 2

[Irvan Kurniawan (:sourc7)]

It looks like related to my reported Bug 1798219 which involve fullscreen race condition + reuse popup window, this one is more reliable and straight-forward to reproduce.

Comment 3

[Andrew McCreight [:mccr8]]

Edgar, could you take a look? Thanks.

Comment 4

[Daniel Veditz [:dveditz]]

It's more plausible you could elicit this set of actions from a user. Not completely sold on the rating, but it does seem more "high" ish.

note: if, like me, you have disabled the ability to resize, move, and close windows this testcase won't work; you will have to revert those prefs. We really ought to make those the defaults for people -- no one's using those abilities for anything good.

Comment 5

[Edgar Chen [:edgar]]

There are two things need to check,
1). We don’t check user gestures on window.open() which is to open an existing window (with the same window name), but Chrome does, need to check how Webkit behaves and also spec.
2). I cannot reproduce the issue on macOS, seems like requesting fullscreen to cocoa widget will bring a background widget window to foreground, have not yet checked Windows.

Comment 6

[Edgar Chen [:edgar]]

(In reply to Edgar Chen [:edgar] from comment #5)

2). I cannot reproduce the issue on macOS, seems like requesting fullscreen to cocoa widget will bring a background widget window to foreground, have not yet checked Windows.

Hmm, I think the reason that I could not reproduce this on macOS is because of the fullscreen transition,
https://searchfox.org/mozilla-central/rev/3ede9deb876ad5d6389cb51b371d4a4c8d788deb/modules/libpref/init/all.js#3381-3388, which delay the fullscreen request a bit and make the fullscreen request could switch focus back to the fullscreen window. If I turn the fullscreen transition off, I could also reproduce this on macOS.

Comment 7

[Edgar Chen [:edgar]]

In this case, window.open() which would bring the existing window get called before the requestFullscreen(), but parent process receive the request to raise the popup window after the fullscreen request, I think it is hard to ensure the request order that arrives parent process, but anyway, we should leave fullscreen if another window get raised.

FocusManager tries to handle that in https://searchfox.org/mozilla-central/rev/aa3ccd258b64abfd4c5ce56c1f512bc7f65b844c/dom/base/nsFocusManager.cpp#1659-1687, but it doesn't work for this case. And it doesn't work for the case that window is raised by clicking link, either. We should fix them together.

Comment 8

[Edgar Chen [:edgar]]

Attachment: Bug 1814597; r?smaug

Comment 9

[Edgar Chen [:edgar]]

Comment on attachment 9321006 [details]
Bug 1814597; r?smaug

Security Approval Request

• How easily could an exploit be constructed based on the patch?: The patch likely makes it obvious what the issue might be.
• 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?: No
• If not, how different, hard to create, and risky will they be?: I would expect that this patch could apply to all branches directly.
• How likely is this patch to cause regressions; how much testing does it need?: Should be safe as we have multiple existing tests cases for different scenarios, e.g.

• https://searchfox.org/mozilla-central/rev/2af0d81d29bcd264083e04a2473d82a91f0f7eb6/browser/base/content/test/fullscreen/browser_fullscreen_window_focus.js
• https://searchfox.org/mozilla-central/rev/2af0d81d29bcd264083e04a2473d82a91f0f7eb6/browser/base/content/test/fullscreen/browser_fullscreen_window_open.js
  And more tests will be added in bug 1819756.

• Is Android affected?: No

Comment 10

[Tom Ritter [:tjr]]

Comment on attachment 9321006 [details]
Bug 1814597; r?smaug

Approved to land and uplift.

Comment 11

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

r=smaug
https://hg.mozilla.org/integration/autoland/rev/f75229a5f6abc1d6c52537c3ff08e966285767a4
https://hg.mozilla.org/mozilla-central/rev/f75229a5f6ab

Comment 12

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

The patch landed in nightly and beta is affected.
:edgar, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox112 to wontfix.

For more information, please visit auto_nag documentation.

Comment 13

[Edgar Chen [:edgar]]

Comment on attachment 9315566 [details]
Firefox - Multiple requestFullscreen repeatedly + reuse popup window name able to overlap fullscreen toast.mp4

Beta/Release Uplift Approval Request

• User impact if declined: Fullscreen warning notification is overlapped by popup window, which could lead to address bar UI spoofing.
• 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: Follow steps in comment# 0.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Should be safe as we have multiple existing tests cases for different scenarios, e.g.

• https://searchfox.org/mozilla-central/rev/2af0d81d29bcd264083e04a2473d82a91f0f7eb6/browser/base/content/test/fullscreen/browser_fullscreen_window_focus.js
• https://searchfox.org/mozilla-central/rev/2af0d81d29bcd264083e04a2473d82a91f0f7eb6/browser/base/content/test/fullscreen/browser_fullscreen_window_open.js
• And more tests will be added in bug 1819756.

• String changes made/needed: None
• Is Android affected?: No

Comment 14

[Dianna Smith [:diannaS]]

Comment on attachment 9321006 [details]
Bug 1814597; r?smaug

Approved for 112.0b3

Comment 15

[Dianna Smith [:diannaS]]

https://hg.mozilla.org/releases/mozilla-beta/rev/77aef6e97578

Comment 16

[Dianna Smith [:diannaS]]

Comment on attachment 9321006 [details]
Bug 1814597; r?smaug

Approved for 102.10esr

Comment 17

[Dianna Smith [:diannaS]]

https://hg.mozilla.org/releases/mozilla-esr102/rev/104fefb06fc6

Comment 18

[Ciprian Georgiu, Desktop QA]

I was able to reproduce the bug using the STR from comment 0, on an affected Nightly build (2023-02-02). I've checked with macOS 11.

The issue is verified as fixed on latest Nightly 113.0a1 and Beta 112.0b4 under macOS 11, Win 10 x64 and Ubuntu 18.04 x64. I'll verify this on ESR 102.10 as well once the builds are available in treeherder.

Comment 19

[Ciprian Georgiu, Desktop QA]

This is also verified as fixed on Esr 102.10, under macOS 11, Win 11 and Ubuntu 18.04 x64.

Comment 20

[Tom Ritter [:tjr]]

Attachment: advisory.txt