1842187 - (CVE-2024-11697) Bypass Open Executable file? Dialog, Executable file may contain viruses or other malicious code

Status: VERIFIED FIXED

(Firefox :: Downloads Panel, defect)

Description

[Umar Farooq [:Puf]]

Attachment: Puf Poc Firefox.mp4

Firefox Version: [115.0] + [117.0a1]
Operating System: [Windows 10]

Bypass Open Executable file? Executable file may contain viruses or other malicious code Dialog.
In this Vulnerability Attacker Can Easily Bypass Open Executable file? Dialog Using " Enter Key "

Once the User/Victim Click on Download Button the Executable file gets Downloaded (ex .hta , .diagcab ) and then it will Display the Progress of Ongoing Downloads Dialog, Attacker Will Instruct User to Key Press EnterKey Two Times

Once User KeyPress Two Times EnterKey the Executable file Execute. Without Knowing User/Victim Malicious File's Executes in System

Verified In:
Firefox Nightly 117.0a1 [Windows 10] (64-bit)
Firefox 116.0 beta [Windows 10] (64-bit)

Steps To Reproduce:

1. Open Puf.Html
2. Click On [ Click Me #1] = It Will Download Executable file
3. Now Keypress Enter key Two Times
4. Successfully File Execute

To Fix

1. consider introducing a short delay to Executable file? Dialog
2. Prevent KeyPress in Ongoing Downloads Dialog

Comment 1

[Umar Farooq [:Puf]]

Attachment: Puf.html (broken: relative link to download)

Comment 2

[Daniel Veditz [:dveditz]]

The testcase contains a broken relative link. To use it you'll have to download and put an appropriately named file next to it. The testcase uses the download attribute to rename the downloaded .diacab file to MicrosoftOpenMe.application. The download attribute won't rename files if the URL is not same-origin with the document so don't just point at one that's online. On the other hand, both .diagcab and .application are treated as executable types in nsLocalFileCommon.cpp so maybe that part of the POC is unnecessary?

Puf: What is the actual file type of the downloaded contents? The movie shows the troubleshooter launching which makes me think it really is a .diagcab... is it really an .application file that is coincidentally set up to launch the same program? Did the download attribute fail to rename (because your own testcase points to an external .diagcab)? Does windows ignore the extension and sniff the file contents to pick the application?

I'm confused by the alert dialog that shows in the movie

• this is not in the attached testcase. Is it required?
• if there was an alert when you made the recording, how did the keystrokes activate the download panel? Alerts are supposed to be modal. Granted, they are "tab" modal which gives them independence from the browser UI (e.g. you can change tabs without having to dismiss it), but if I see a modal prompt showing I 100% would expect that's what will have focus for my keystrokes

Gijs: Are we queuing keystrokes in the download panel before a download finishes? Giving the panel focus makes some sense for accessibility, but it's also potentially dangerous. We definitely shouldn't be saving keystrokes for the "open executable file?" dialog--looks like this regressed (see bug 1749028 / bug 1743226)

Comment 3

[Umar Farooq [:Puf]]

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

The testcase contains a broken relative link. To use it you'll have to download and put an appropriately named file next to it. The testcase uses the download attribute to rename the downloaded .diacab file to MicrosoftOpenMe.application. The download attribute won't rename files if the URL is not same-origin with the document so don't just point at one that's online. On the other hand, both .diagcab and .application are treated as executable types in nsLocalFileCommon.cpp so maybe that part of the POC is unnecessary?
Thank You Deniel I Have Added the Same-origin File I was testing with executable files, So I keep Renaming Files From .diagcab to .application
Just to Test it

Puf: What is the actual file type of the downloaded contents? The movie shows the troubleshooter launching which makes me think it really is a .diagcab... is it really an .application file that is coincidentally set up to launch the same program? Did the download attribute fail to rename (because your own testcase points to an external .diagcab)? Does windows ignore the extension and sniff the file contents to pick the application?
The Actual file is .diagcab There is Mistake in My Attached POC File , let me Change it. and I will Update a New Attached File

I'm confused by the alert dialog that shows in the movie

• this is not in the attached testcase. Is it required?
• if there was an alert when you made the recording, how did the keystrokes activate the download panel? Alerts are supposed to be modal. Granted, they are "tab" modal which gives them independence from the browser UI (e.g. you can change tabs without having to dismiss it), but if I see a modal prompt showing I 100% would expect that's what will have focus for my keystrokes
  Here After Downloading File, Automatically Open " Progress of Ongoing Downloads Dialog " will open, User Keypress enter Two Times the File Executes

"Progress of Ongoing Downloads Dialog" still thinks it has Exact Focus When it is Open.

In First Enter It Show's File Exactable File Warning
The 2nd Enter Keypress Press "Ok" On Exactable File Warning Dialog
If Enter keystrokes is Fast, it Will Hide Exactable File Warning

Comment 4

[Umar Farooq [:Puf]]

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

The testcase contains a broken relative link. To use it you'll have to download and put an appropriately named file next to it. The testcase uses the download attribute to rename the downloaded .diacab file to MicrosoftOpenMe.application. The download attribute won't rename files if the URL is not same-origin with the document so don't just point at one that's online. On the other hand, both .diagcab and .application are treated as executable types in nsLocalFileCommon.cpp so maybe that part of the POC is unnecessary?

Thank You Deniel I Have Added the Same-origin File I was testing with executable files, So I keep Renaming Files From .diagcab to .application
Just to Test it

Puf: What is the actual file type of the downloaded contents? The movie shows the troubleshooter launching which makes me think it really is a .diagcab... is it really an .application file that is coincidentally set up to launch the same program? Did the download attribute fail to rename (because your own testcase points to an external .diagcab)? Does windows ignore the extension and sniff the file contents to pick the application?

The Actual file is .diagcab There is Mistake in My Attached POC File , let me Change it. and I will Update a New Attached File it is Not extension issue But Here "Progress of Ongoing Downloads Dialog" Focus Issue

I'm confused by the alert dialog that shows in the movie

• this is not in the attached testcase. Is it required?
• if there was an alert when you made the recording, how did the keystrokes activate the download panel? Alerts are supposed to be modal. Granted, they are "tab" modal which gives them independence from the browser UI (e.g. you can change tabs without having to dismiss it), but if I see a modal prompt showing I 100% would expect that's what will have focus for my keystrokes

"Progress of Ongoing Downloads Dialog" still thinks it has Exact Focus When it is Open.

In First Enter It Show's File Exactable File Warning
The 2nd Enter Keypress Press "Ok" On Exactable File Warning Dialog
If Enter keystrokes is Fast, it Will Hide Exactable File Warning

Comment 5

[Umar Farooq [:Puf]]

Attachment: PufNew.html

Comment 6

[Umar Farooq [:Puf]]

Step To Create File

1. Create a File In Your desktop
2. Rename to MicrosoftOpenMe.diagcab You can Add Any Dangerous Filetype
3. Upload it to Localhost Server

Comment 7

[:Gijs (away/busy until Mar 10)]

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

Gijs: Are we queuing keystrokes in the download panel before a download finishes?

Less that and more that we allow you to click the download while it's downloading in order to open it when the download finishes (bug 1711053). That shouldn't be happening during the timeout from bug 1749028 / 1743226, though.

We definitely shouldn't be saving keystrokes for the "open executable file?" dialog

I agree, and we don't, certainly not deliberately on the frontend side. But there's no timeout in that dialog because there's a timeout on the download panel.

--looks like this regressed (see bug 1749028 / bug 1743226)

I can't tell 100% for sure from the description in this bug, or from the screencast, what is going on, as it's impossible to tell when the user presses any keys. I don't have access to my Windows machine right now (I just moved house), so can't reproduce myself. But it sure looks like the user waits for the download panel to be enabled before pressing enter, and in that case I don't think there's any surprise here? The download panel is definitely initially disabled when opened, and almost 2 seconds elapse before it disappears (presumably due to the enter keypress), during which it becomes re-enabled for clicks. There's visual jitter in the video because the page itself pops an alert, but afaict that is immaterial to the issue described. So I actually am not sure anything's wrong here? Can you be more specific?

Comment 8

[Umar Farooq [:Puf]]

Attachment: New Update Video.mp4

There is New Update to this Vulnerability.

If We Add Two Files in One Function to Download Dangerous File, it will not Show Progress of Ongoing Downloads Dialog and 2 seconds Delay/ elapse

Step To Reproduce :

1. Create putty.diagcab file Host in Your Server
2. Host Attached Code File in Your Server
3. Open Link
4. Click [ Click Me ]
5. Now Open Download Icon In Firefox
6. Double KeyPress [Enter] Key
7. Done

Comment 9

[Umar Farooq [:Puf]]

Attachment: NewPocCode.html

Comment 10

[:Gijs (away/busy until Mar 10)]

(In reply to Umar Farooq [:Puf] from comment #8)

Created attachment 9344055 [details]
New Update Video.mp4

There is New Update to this Vulnerability.

If We Add Two Files in One Function to Download Dangerous File, it will not Show Progress of Ongoing Downloads Dialog

Looks like we don't show the dialog effectively if 2 files get downloaded quickly. That's a bug, but not a security bug.

and 2 seconds Delay/ elapse

<snip>

5. Now Open Download Icon In Firefox

But you have to convince the user to do this and then double-press enter. There's no clickjacking delay when the user manually opens the downloads panel because, well... you can't keyboard-jack them into doing that. That's why there's no delay.

I don't think this rises to the level of a security vulnerability that the browser can mitigate against. If you can convince the user to jump through all these hoops, you could probably convince them to run arbitrary stuff from cmd...

Comment 11

[:Gijs (away/busy until Mar 10)]

Given the comments in bug 1921013 I'm curious if you have additional thoughts here, :mccr8.

Comment 12

[:Gijs (away/busy until Mar 10)]

Actually maybe adding another delay to the executable warning dialog will be sufficient here, even if I don't exactly love that solution. It means we have a clickjacking protection first on opening any file, and then again to say yes you really want to open the executable file. :-\

Comment 13

[:Gijs (away/busy until Mar 10)]

Attachment: Bug 1842187

Comment 14

[Umar Farooq [:Puf]]

Attachment: Latest POC.mp4

Comment 15

[Umar Farooq [:Puf]]

Attachment: Screenshot.PNG

Thank you for the update
I'm not an expert but I Would like to give a fixing suggestion regarding this Bug

I think we can fix in another way how if we set focus on [Cancel] Button?
this will stop executing dangerous files on keypress [Enter] key

Comment 16

[:Gijs (away/busy until Mar 10)]

(In reply to Umar Farooq [:Puf] from comment #15)

Created attachment 9427769 [details]
Screenshot.PNG

Thank you for the update
I'm not an expert but I Would like to give a fixing suggestion regarding this Bug

I think we can fix in another way how if we set focus on [Cancel] Button?
this will stop executing dangerous files on keypress [Enter] key

Because of how the dialog is implemented this is not straightforward. It would also break established patterns, and would break habits of users who are actively using "executable" file types. (the delay will also do that but will only require people to wait instead of learning to press different keys)

Comment 17

[Umar Farooq [:Puf]]

(In reply to :Gijs (he/him) from comment #16)

Because of how the dialog is implemented this is not straightforward. It would also break established patterns, and would break habits of users who are actively using "executable" file types. (the delay will also do that but will only require people to wait instead of learning to press different keys)

Thanks for the details, appreciate the details

Comment 18

[Umar Farooq [:Puf]]

Any updates here.
Thanks!

Comment 19

[:Gijs (away/busy until Mar 10)]

(In reply to Umar Farooq [:Puf] from comment #18)

Any updates here.
Thanks!

All the updates are on the bug. There is a patch, which you can see, and you can see the review comments there, where I was asked to create a[n automated] test, which I have not yet had time to do - there's been a lot of higher-priority stuff across my desk. As a result, the patch hasn't landed yet. At this point in the 132 beta cycle with last betas being built today and this not having landed on mozilla-central yet, it probably wouldn't get uplifted so I expect it not to land until after next week.

Does this make sense / can you see all that? Because asking for updates just... emails everyone but doesn't help move the bug forward, and there's not really anything to tell you beyond what is visible in the bug and otherwise public information - for this bug but indeed any bug in bugzilla. Unlike other companies' security bug trackers, we don't really have a second/secret tracker where all the actual work happens. Everything is here. You can just see it right here on the ticket. So for me and other folks working on security bugs, pings like this are annoying and distract us from doing actual work. Please don't.

Comment 20

[Umar Farooq [:Puf]]

I hope you're well
I apologize for the mistake I made
I appreciate your explanation and giving me your valuable time

I Just asked update casually
you can give me update regarding this issue whenever you got free time
I just wanted to ensure there is some progress going on here

Sorry to burden you with this
I know you’re busy, and I’m sorry to disturb you
I hope I’m not disturbing you with this message.

Comment 21

[Marco Bonardo [:mak]]

I'm going to file a separate bug to add a CI test for this, as we're unlikely to find the time for it, and it could still only land in a few months. Let's try to land the fix that is ready.

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/452030531f98
r=mak,pbz

Comment 23

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

https://hg.mozilla.org/mozilla-central/rev/452030531f98

Comment 24

[Marco Bonardo [:mak]]

Attachment: Bug 1842187

Original Revision: https://phabricator.services.mozilla.com/D223948

Comment 25

[Phabricator Automation]

beta Uplift Approval Request

• User impact if declined: sec-mod, using social engineering malicious site may convince user to launch executable inadvertently
• Code covered by automated testing: no
• Fix verified in Nightly: no
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: comment 8 has usable steps
• Risk associated with taking this patch: low
• Explanation of risk level: Delaying enabling of a button through a simple flag
• String changes made/needed: none
• Is Android affected?: no

Comment 26

[Marco Bonardo [:mak]]

Attachment: Bug 1842187

Original Revision: https://phabricator.services.mozilla.com/D223948

Comment 27

[Phabricator Automation]

esr128 Uplift Approval Request

• User impact if declined: sec-mod, using social engineering malicious site may convince user to launch executable inadvertently
• Code covered by automated testing: no
• Fix verified in Nightly: no
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: comment 8 has usable steps
• Risk associated with taking this patch: low
• Explanation of risk level: Delaying enabling of a button through a simple flag
• String changes made/needed: none
• Is Android affected?: no

Comment 28

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/82da4ec85d04

Comment 29

[Alexandru Trif, Desktop Test Engineering [:atrif]]

I reproduced the issue with Firefox 132.0.2 on Windows 10x64 by following the steps in comment 8 and using the test case from comment 9. After downloading the files and manually opening the Download Panel, pressing the Enter key twice caused the file to open.

The issue no longer occurs in Firefox 133.0b8 (20241112132840) from comment 28 and 134.0a1 (2024-11-12) on Windows 10x64. After downloading the files, then manually opening the Download Panel and pressing the Enter key twice consecutively, the file no longer opens because the OK button is temporarily disabled.

I also saw that there might be an issue that the download panel is not opened while downloading two files as stated in comment 10. Should someone open an issue for this? Thank you!

Comment 30

[Marco Bonardo [:mak]]

(In reply to Alexandru Trif, Desktop Test Engineering [:atrif] from comment #29)

I also saw that there might be an issue that the download panel is not opened while downloading two files as stated in comment 10. Should someone open an issue for this? Thank you!

Based on the code logic we only show the panel if theres 0 or 1 download progressing, if there's 2 progressing we don't.
What happens is not wrong according to the code, though I think the intent was slightly different, it basically doesn't handle well many downloads started in a short timeframe. It's a very minor bug, if you want to file it.

Comment 31

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr128/rev/936e95e3b008

Comment 32

[Simon Friedberger [:simonf]]

Since this requires an explicit action to get to the question and then still multiple enter presses it is unlikely that users can be tricked with it.

Comment 33

[Umar Farooq [:Puf]]

Attachment: POC Reproduce Video.mp4

the Attack is Simple
There is no need for multiple " Enter " key

With Two Steps it can easily executes malicious executable and avoid the Warning dialog

1. Click on the Link
2. Press Two Times " Enter key "

The download panel gains focus and successfully the malicious executable will be launched and without showing the Warning dialog

i have attached the reproduce video

Comment 34

[Umar Farooq [:Puf]]

Attachment: PufIndex.html

Step To Reproduce:

1. Click on Click Me link

2. Double 2-3 times Keypress [Enter] Key

successfully the malicious executable will be launched and without showing the Warning dialog

I kindly request Bounty Committee Please evaluate this Vulnerability report again it will be helpful for me

Comment 35

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Verified fixed with Firefox 128.5.0esr on Windows 10x64. After downloading the files, then manually opening the Download Panel and pressing the Enter key twice consecutively, the file no longer opens because the OK button is temporarily disabled.

Comment 36

[Tom Ritter [:tjr] (OOTO until April)]

Attachment: advisory.txt