1887343 - (CVE-2024-4776) Window may remain disabled after file dialog is shown in full-screen

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect)

Description

[Raphael]

Attachment: crash.html

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36

Steps to reproduce:

Open the attachment
Double-click the area
Select the image
Press ESC

The Firefox browser version 126.0a1 completely freezes and does not respond to commands.
Report: https://crash-stats.mozilla.org/report/index/4a5ad2e3-a855-42de-8227-fb7370240323#tab-details

Comment 1

[Raphael]

In Firefox ESR, no crashes have been found, as the provided exploit does not pose a threat. For the Firefox Nightly version 125.0a1, the exploit appears more convincing.
I also confirm the crash in version 124 Stable.

Comment 2

[Andrew McCreight [:mccr8]]

Do you have the pref layers.gpu-process.crash-also-crashes-browser set to true? The stack suggests this is why it crashed, but it appears to be false by default. Crashing the GPU process is not great, but it isn't necessarily a security issue. Due to bad graphics drivers, the browser is expected to be able to deal with a crashing GPU process without the user noticing.

Comment 3

[Andrew McCreight [:mccr8]]

The steps to reproduce didn't quite work for me as described on MacOS. I did a double click, which caused it to go full screen, but then I had to click again to make the file selector appear. I tried a random cat image I found online, and the image appeared without any issue. When you say "the issue", do you mean a specific image causes this problems or a specific one?

The test case looks very DOM-y, but the stack makes it look like the GPU process crashed, so maybe this is more graphics.

Comment 4

[Raphael]

Attachment: Nightly 125.mp4

To reproduce the vulnerability, you need to press ESC, which causes a crash. I have added a video for clarification. I hid the error because the exploit itself can be reproduced in Firefox 125 to spoof the address bar.
https://drive.google.com/file/d/1RY8e1dKW8Ye5a5ouAS6gkztSEHqyRV3v/view?usp=sharing

Comment 5

[Raphael]

The graphics do not affect the crash; instead, something else breaks. It seems as though the file selection windows are not being unloaded and remain stuck in an invisible window. It is worth noting that the browser is unable to stop the process and unload the window on its own, and the only way to exit the browser is to forcefully terminate the process through the task manager. This behavior fits the description of a denial-of-service (DoS) attack.

Comment 6

[Andrew McCreight [:mccr8]]

I still haven't been able to reproduce a crash, though I don't have that pref set so it might be crashing without me noticing.

Comment 7

[Tyson Smith [:tsmith]]

I was able to reproduce this a few times but it is not 100% reliable. I had to close the browser from task manager when I triggered the issue.

Comment 8

[Andrew McCreight [:mccr8]]

Ray, could this be related to your Windows file picker work?

Comment 9

[Ray Kraesig [:rkraesig]]

(In reply to Andrew McCreight [:mccr8] from comment #8)

Ray, could this be related to your Windows file picker work?

Yes, almost certainly. What appears to be happening here — although I don't yet know how or why — is that the window is still WM_DISABLED after the file dialog is dismissed. Other Firefox windows, if there were any open, are unaffected. That shouldn't cause a crash, though... and I haven't been able to induce one either.

@Raphael, just to check that this isn't a language issue — are you referring to the state Firefox is in after pressing ESC, where you can't interact with it and have to kill it, as "crashed"? Or have you been able to make Firefox disappear without using Task Manager?

Comment 10

[Raphael]

i mistakenly believed that the browser was malfunctioning, it seemed like a failure. The crash was caused when I closed the browser through the task manager.
So far, I've only been able to reproduce the problem in Windows, it appears that other operating systems are not affected. This issue allows attackers to control the browser, possibly showing advertisements that cannot be closed (auto-playing videos, new windows, or redirects to other websites).

Comment 11

[Ray Kraesig [:rkraesig]]

Attachment: Bug 1887343 - Store only window-chrome style-flags when going fullscreen r?#win-reviewers

When stripping and restoring window chrome, don't modify or retain any
flags other than window-chrome flags.

This also lets us remove a tiny bit of thirteen-year-old special-case
logic (dating back to bug 629860) which tried to fix up a different bit
of stale state.

Comment 12

[Ray Kraesig [:rkraesig]]

It's worth documenting here that the issue was due to the fullscreen-entry logic saving, and then the fullscreen-exit logic restoring, the window-style flags on entry and exit into fullscreen mode. This unfortunately included WS_DISABLED, which it had no business fiddling with.

The solution is simply to cache and restore only those window-style flags which deal with window decorations that actually need to change when going fullscreen.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/29ce18e61ece
Store only window-chrome style-flags when going fullscreen  r=win-reviewers,handyman

Comment 14

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/29ce18e61ece

Comment 15

[Jesse Schwartzentruber (:truber)]

Attachment: advisory.txt

Comment 16

[Daniel Veditz [:dveditz]]

Sorry for the burst of bugspam: filter on tinkling-glitter-filtrate
Adding reporter-external keyword to security bugs found by non-employees for accounting reasons