1811663 - "Open Executable File?" Prompt's default choice is not safe

Status: RESOLVED WONTFIX

(Firefox :: Downloads Panel, defect)

Description

[[:old-account]]

Attachment: test.bat

Tested with the latest version of Firefox with default settings on Windows operating systems.

In Firefox, the "Open Executable File?" prompt is displayed when you click the downloaded bat file. But the default choice is "OK". So, if you were holding down the Enter key, this prompt may be bypassed.

This vulnerability can be exploited with something like "Press the Enter key for 2 seconds on the downloaded file." (This trick is similar to that used in CVE-2022-0337.)

I want to know if this vulnerability qualifies for a bug bounty, and apart from that, I want this vulnerability to be fixed so that many people can safely use Firefox.

Please let me know if you need more information.

Comment 1

[:Gijs (he/him)]

(In reply to Suhyun An [:movptr] from comment #0)

Created attachment 9313400 [details]
test.bat

Tested with the latest version of Firefox with default settings on Windows operating systems.

In Firefox, the "Open Executable File?" prompt is displayed when you click the downloaded bat file. But the default choice is "OK". So, if you were holding down the Enter key, this prompt may be bypassed.

This dialog only comes up once you actually click the file in the downloads list, right? And we already did work to avoid enter/click from doing that within the first few ms of the panel being opened (when it's opened automatically). So my understanding is that an attacker cannot clickjack/keyjack this without jumping through hoops around when users click / press enter / etc.

Comment 2

[[:old-account]]

That's right. Attackers need more vulnerabilities or social engineering components to exploit this vulnerability.

The crux of this vulnerability is "Open Executable File?" prompt can be bypassed. Naturally, a separate vulnerability or social engineering component is required to bypass the download panel protection.

Comment 3

[:Gijs (he/him)]

(In reply to Suhyun An [:movptr] from comment #2)

That's right. Attackers need more vulnerabilities or social engineering components to exploit this vulnerability.

The crux of this vulnerability is "Open Executable File?" prompt can be bypassed. Naturally, a separate vulnerability or social engineering component is required to bypass the download panel protection.

I think if you're managing to social engineer someone into opening the file (despite the clickjack/keyjack protection that's already in place on the downloads panel), you can probably social engineer them into accepting this dialog. You can't realistically clickjack/keyjack the "open" operation (if you could, I'd be happy to look at fixing that instead) and so adding clickjack/keyjack protection to this additional dialog, which necessarily comes after trying to open the file, is pointless - it would only frustrate people who encounter this dialog while running things they do trust. Balancing those demands, I think we should wontfix this bug. Freddy/Dan, wdyt?

Comment 4

[Frederik Braun [:freddy]]

Yes, I agree with Gijs. We have UI in between and the open prompt is designed to protect against. The attacker needs another bug or some social engineering to get the user to click, which we do not see as part of this bug report.

The only thing that would sway me at this point would be a believable proof of concept similar to the attached code (and the video) that we can see in the linked chrome bug (CVE-2022-0337). Let's close this (and I'm happy to revisit a proof of concept in another, newly reported bug if it comes up)

Comment 5

[:Gijs (he/him)]

Closing this out per comment #3 / comment #4.

Comment 6

[Daniel Veditz [:dveditz]]

Note that the underlying problem in the referenced Chrome issue was NOT downloading a file, but the expansion of environment variables in the return values from the non-standard window.showSaveFilePicker().

• Firefox does not support window.showSaveFilePicker()
• we addressed the environment variable issue in the Windows native file picker in bug 1765049 (CVE-2022-31739)

Comment 7

[[:old-account]]

Thank you for checking my report.