[Description:]

On Windows, when adding the .exe extension with "Always Open" it will trigger executing the executable.

[Environment:]

97.0b8
98.0a1 2022-01-26

[Steps:]

1. New profile.
2. Load https://archive.mozilla.org/pub/firefox/candidates/96.0.1-candidates/build1/win64/en-US/
3. Click on an .exe
4. After download is complete, right click in the Download Pannel and set "Always Open Similar Files"
5. Click again on an .exe from the https://archive.mozilla.org/pub/firefox/candidates/96.0.1-candidates/build1/win64/en-US/

[Actual Result:]

Exe file is added to the Applications with always ask, but it behaves as auto-open. "Always Open Similar files" remains checked for the .exe filetype.

[Expected Result:]

I don't believe we should let .exe files autoexecute on Windows

[Note:]

The icon for the "always ask" that is added on "Always Open .. " is an action icon, not the "always ask" icon - subject we are touching on in bug 1740841 and also in https://bugzilla.mozilla.org/show_bug.cgi?id=1742693#c7

Although I've logged this issue against Windows, since auto-executing *.exe is most concerning there, it is similar to auto-open for mac and ubuntu aswell, with obvious difference that natively won't have the same impact, question mark being that most likely would be surprising(or less?) if there is something akin to windows VM or emulator that registers as default with OS for .exe (not sure how this shall work though).
Gijs, depending on your thoughts and approach in regards to mac and ubuntu handling of this case, let me know if i should spin separate bugs or extend this one + if any additional testing needed.

I think this is a bit worse than S3.

Going to mark this sec-sensitive to be on the safe side.

When this code runs, the GetTargetFile helper hands us the part file.
That ends in .part.
Thus, we never detect it as executable on Windows.
However, we will have previously cached the mTempFileIsExecutable property,
and that has the information we want. I've left the other code in case there
are other cases where that info is correct - erring on the side of caution
seems wise here.

Assigning to 'action' doesn't do anything, unfortunately. We still end up
executing the file. Because the prefs indicate 'always ask', that's what I've
gone for here, as that does work... I'll use another patch to try to stop
people getting into this situation to begin with.

Depends on D137145

Depends on D137152

I landed without sec approval, https://hg.mozilla.org/integration/autoland/pushloghtml?tochange=a278575bb4ec6e76c8c4cf7d19b48466af8cf2a5&fromchange=b5f64e3ad9a52b3c7a9c049147c1f58a76bd0f71, because this appears to only affect 97 and later. I scrubbed the commit messages for the first and second commit because in theory (with some additional work by an attacker?) they might be usable without the download improvements pref, and I didn't want to give out any hints. Either way, given the user interaction required I'm not sure this is more than sec-moderate at most - if you're going to convince someone to right click an executable and say "always open", surely it would be easier to just have them open your malware app once (left click)...

r=mhowell,mtigley
https://hg.mozilla.org/integration/autoland/rev/7e2c41fe448566b4013bda792a305828add2d78c
https://hg.mozilla.org/mozilla-central/rev/7e2c41fe4485

r=mtigley
https://hg.mozilla.org/integration/autoland/rev/b332f71d14c38bff371dacbb370ed67198a1ef4e
https://hg.mozilla.org/mozilla-central/rev/b332f71d14c3

check if target is executable before offering always opening, r=mhowell,mtigley
https://hg.mozilla.org/integration/autoland/rev/a278575bb4ec6e76c8c4cf7d19b48466af8cf2a5
https://hg.mozilla.org/mozilla-central/rev/a278575bb4ec

Comment on attachment 9261045 [details]
Bug 1752159, r?mhowell,mtigley

Beta/Release Uplift Approval Request

• User impact if declined: Security / shoot-self-in-foot risks for our users
• 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: See comment 0. Additionally, if you set exe files to always open on an old/vulnerable build using the steps in that comment, once you update to a new build, they shouldn't auto-open anymore (instead they will prompt).
• List of other uplifts needed: n/a
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): These are all pretty straightforward/small patches. The only potentially risky one would be this one (D137145), which is moving some existing code around and switching from automatically saving to disk to automatically prompting what to do.
• String changes made/needed: Nope

Comment on attachment 9261045 [details]
Bug 1752159, r?mhowell,mtigley

Nice find, approved for 97.0rc1.

https://hg.mozilla.org/releases/mozilla-beta/rev/983965bd40ef
https://hg.mozilla.org/releases/mozilla-beta/rev/eb83e47844c3
https://hg.mozilla.org/releases/mozilla-beta/rev/ab061bd3b0ae

.exe files downloaded with latest Nightly 98.0a1 (2022-01-31) in new profiles don't have the option Always Open Similar Files - verified across platforms.

When performing an upgrade, from a profile where .exe was set to always open to latest Nightly, the application handler still shows EXE file under Win 10 & OSX 10.16 and Use Archive Manager - Ubuntu 21.

• In this scenario, MacOS and Ubuntu still try to automatically open the .exe files, but since this extension is not recognized by the system, nothing happens in the end (see attachment).
• For Win 10, the Opening.. dialog with Save File and Cancel is displayed when downloading a .exe file, with a profile that was previously set to "Always ask".

Also verified comment 12 with 97.0 RC1 (2022-01-31) that new profiles doesn't correctly have the Always Open Similar Files for .exe files on all affected versions (Windows 10, Ubuntu 20, Mac 11) and the Always Open Similar Files is not available for .exe files .
Additionally, the upgrade path was verified as well (this assumes that you could and set the Always Open Similar Files for .exe files on an affected version):
-on Windows after upgrade, after first .exe download, the always ask for .exe files would be set in Application handlers
-on Mac and Ubuntu, the update path would only fix the Always Open Similar Files availability for .exe files, but the auto-open would still be available (see commment #12 aswell)

Marking as verified since the main concern here was the Windows behavior.

I initially thought to file a follow-up, for the above, but I don't think the Mac and Ubuntu behaviors on upgrade is of any concern, due to the fact that the instances on which ```.exe`` extensions for Mac + Ubuntu have been added are low impact and also probably close to neglijable amount (this would impact just the population that used the feature on 96nightly - 97 beta). :Gijs, do you think the auto-open for ubuntu/mac deserves a followup?