Closed Bug 1940162 (CVE-2025-1019) Opened 9 months ago Closed 9 months ago

reportValidity to steal window focus able to overlap fullscreen notification toast

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
136 Branch
Tracking Flags:
Tracking Status
firefox-esr115 --- unaffected
firefox-esr128 --- unaffected
firefox134 --- wontfix
firefox135 + verified
firefox136 + verified

People

(Reporter: sourc7, Assigned: emilio)

References

(Regression)

Details

(4 keywords, Whiteboard: [client-bounty-form][adv-main135+])

Attachments

(5 files)

xtestcase.bundle.html
12.35 KB, text/html
Details
reportValidity steal window focus to overlap fullscreen notification toast.mp4
200.15 KB, video/mp4
Details
reportValidity steal window focus with right-click method.mp4
223.13 KB, video/mp4
Details
Bug 1940162 - Use SWP_NOOWNERZORDER when showing popups. r=#win-reviewers
48 bytes, text/x-phabricator-request
RyanVM
: approval-mozilla-beta+
pascalc
: approval-mozilla-release-
tjr
: sec-approval+
Details | Review
advisory.txt
223 bytes, text/plain
Details
Attached file xtestcase.bundle.html —

When user on web page A window, then other web page B trigger JS reportValidity, the web page B window able to steal focus from page A window.

After launching both site in popup window, then trigger reportValidity repeatedly, it able to steal window focus to overlap fullscreen notification toast on Windows 11.

Tested works on Firefox 134.0 (64-bit) and Firefox Nightly 135.0a1 (2025-01-06) (64-bit) on both my laptop Intel i5-1035G and desktop PC.

When running mozregression, it show it is a regression of Bug 1922956 - Further clean-up widget creation code-paths

Steps to reproduce:

  1. Visit attached xtestcase.bundle.html
  2. Click "Launch Opener Window"
  3. Click "Launch Fullscreen Window"
  4. Click anywhere inside the page
  5. Opener Window shown at the top of fullscreen notification toast

(If still doesn't work, I found a trick by right click before "Launch Fullscreen Window", it will works all the time; on the attached video I perform that without the right-click)

  1. Visit attached xtestcase.bundle.html
  2. Click "Launch Opener Window"
  3. When you see "Launch Fullscreen Window"
  4. Right click
  5. Left click "Launch Fullscreen Window"
  6. Left click anywhere inside the page
  7. Opener Window shown at the top of fullscreen notification toast
Flags: sec-bounty?
Group: firefox-core-security → dom-core-security
Component: Security → DOM: Core & HTML
Keywords: csectype-spoof
Product: Firefox → Core

Setting Regressed by field after analyzing regression range found by mozregression in comment #0.

Keywords: regression
Regressed by: 1922956

:emilio, since you are the author of the regressor, bug 1922956, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Flags: needinfo?(emilio)
See Also: → CVE-2022-22746

This regression reintroduces CVE-2022-22746.

It looks like the notification bar isn't even being shown, not that it's being covered up. If you repeatedly hit ESC to leave fullscreen and then click on the popup to re-enter fullscreen you will never see the notification on any transition. At that point the window that had the reportValidity check could have been closed, and in any case isn't re-activating the validity check.

Flags: needinfo?(echen)
Keywords: sec-high

I was confused as well because I didn't see the fullscreen notification anymore, but that's a more recent regression, see bug 1940698.

So as to avoid raising the owner window to the front. That's the
intention of the code given the comment, but it needs this flag to work.

Assignee: nobody → emilio
Status: NEW → ASSIGNED

So the fullscreen warning is fixed in bug 1940698 (regressor was backed out of beta).

The remaining issue is a z-ordering issue that can be observed with a page like this:

<!doctype html>
<input id="targetElement" autofocus="true" style="opacity: 0">
<button onclick="setTimeout(triggerReportValidity, 4000);">Report in a bit</button>
<script>
targetElement.setCustomValidity("Please wait while we redirecting to page..")
function triggerReportValidity() {
    targetElement.reportValidity()
}
</script>

STR would be:

  • Open that page.
  • Click the button.
  • Press Ctrl+N to create a new window.

ER:

  • The new window is still in the foreground

AR:

  • The old window gets raised.

That's fixed by the patch I just attached.

Flags: needinfo?(emilio)
Flags: needinfo?(echen)
Severity: -- → S2

(In reply to Emilio Cobos Álvarez (:emilio) from comment #8)

ER:

  • The new window is still in the foreground

AR:

  • The old window gets raised.

I can't reproduce using this STR in 136.0a1 (2025-01-07): the new window remains in the foreground.

I can, however, still use the second STR in comment 0. (I've confirmed the patch fixes it.)

The sec-high was on the assumption that the fullscreen notice was not being shown, but that's an unrelated regression. Is this still sec-high?

Flags: needinfo?(dveditz)

Comment on attachment 9446528 [details]
Bug 1940162 - Use SWP_NOOWNERZORDER when showing popups. r=#win-reviewers

Security Approval Request

  • How easily could an exploit be constructed based on the patch?: Not too much I think?
  • 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 branches (beta, release, and/or ESR) are affected by this flaw, and do the release status flags reflect this affected/unaffected state correctly?: beta+release
  • If not all supported branches, which bug introduced the flaw?: 1922956 (kinda, it exposed a pre-existing bug)
  • Do you have backports for the affected branches?: Yes
  • If not, how different, hard to create, and risky will they be?: should apply cleanly or be trivial to rebase
  • How likely is this patch to cause regressions; how much testing does it need?: Relatively unlikely? It's making Windows do less to the z-order of our windows...
  • Is the patch ready to land after security approval is given?: Yes
  • Is Android affected?: No

Beta/Release Uplift Approval Request

  • User impact if declined/Reason for urgency: sec issue
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: comment 0 and/or comment 8
  • List of other uplifts needed: none
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): See above
  • String changes made/needed: none
  • Is Android affected?: No
Attachment #9446528 - Flags: sec-approval?
Attachment #9446528 - Flags: approval-mozilla-release?
Attachment #9446528 - Flags: approval-mozilla-beta?
Flags: qe-verify+

Comment on attachment 9446528 [details]
Bug 1940162 - Use SWP_NOOWNERZORDER when showing popups. r=#win-reviewers

approved to land

Attachment #9446528 - Flags: sec-approval? → sec-approval+

(In reply to Daniel Veditz [:dveditz] from comment #5)

This regression reintroduces CVE-2022-22746.

While in 2022 we were rating fullscreen issues sec-high, in the last few years we have started rating them sec-moderate, so I'm going to adjust the rating here. See here.

Keywords: sec-high → sec-moderate
Flags: needinfo?(dveditz)
See Also: → 1940698
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/3222d6c111d6 Use SWP_NOOWNERZORDER when showing popups. r=win-reviewers,rkraesig

https://hg.mozilla.org/mozilla-central/rev/3222d6c111d6

Group: dom-core-security → core-security-release
Status: ASSIGNED → RESOLVED
Closed: 9 months ago
status-firefox136: affected → fixed
tracking-firefox135: --- → +
Resolution: --- → FIXED
Target Milestone: --- → 136 Branch

Comment on attachment 9446528 [details]
Bug 1940162 - Use SWP_NOOWNERZORDER when showing popups. r=#win-reviewers

Approved for 135.0b4.

Attachment #9446528 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [qa-triaged]

Reproduced the issue using an old Nightly build from 2024-01-10 using the testcase from the comment 0 but not comment 8, verified that using latest Nightly 136.0a1 and Latest Beta 135.0b4 across platforms (Windows 11, macOS 13 and Ubuntu 22.04) this issue is no longer reproducible.

Status: RESOLVED → VERIFIED
status-firefox135: fixed → verified
status-firefox136: fixed → verified
Flags: qe-verify+
Flags: sec-bounty? → sec-bounty+
Attachment #9446528 - Flags: approval-mozilla-release? → approval-mozilla-release-
Whiteboard: [client-bounty-form] → [client-bounty-form][adv-main135+]
Attached file advisory.txt —
Alias: CVE-2025-1019
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: