Opening a downloaded extensionless file can launch a same-named executable on Windows
Categories
(Toolkit :: Downloads API, defect, P1)
Tracking
()
People
(Reporter: dveditz, Assigned: mak)
References
Details
(Keywords: sec-low, Whiteboard: [keep hidden while chrome bug is][post-critsmash-triage][adv-main84+][adv-esr78.6+])
Attachments
(3 files, 1 obsolete file)
Comment hidden (obsolete) |
Reporter | ||
Comment 1•4 years ago
|
||
If a user downloads an extensionless file on Windows and then "Opens" it from the downloads panel, if there is an executable file in the downloads directory with the same name but a .bat
, or .exe
extension (or presumably .com
but untested) that executable will be launched instead.
STR:
- make a copy of
notepad.exe
in your download directory - from a website download the file
notepad
- from the download panel open
notepad
result:notepad.exe
is launched.
The Chrome team couldn't find a way to make Windows open the extensionless file if an executable of the same base name was in the same directory. Their solution was to assume extensionless files were rare, and to treat requests to "Open" them as if it were "Open Folder" instead.
Chrome's patch:
https://chromium.googlesource.com/chromium/src.git/+/8d2c055e9e3308bfe57d4feb7271b13431e79b61
Assignee | ||
Comment 2•4 years ago
|
||
The Chromium solution sounds ok off-hand.
I'm moving this to the Downloads API component, since opening downloads is not just a prerogative of the panel, it sounds like it'd be better to just fix it at the launchDownload() level.
Comment 3•4 years ago
|
||
See also bug 1652520...
Assignee | ||
Comment 4•4 years ago
|
||
(In reply to :Gijs (he/him) from comment #3)
See also bug 1652520...
Though, that is for when a content type is available, isn't it? This would also be a problem with a generic content type
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 5•4 years ago
|
||
Assignee | ||
Comment 6•4 years ago
|
||
Depends on D94268
Assignee | ||
Updated•4 years ago
|
Comment 7•4 years ago
|
||
https://hg.mozilla.org/integration/autoland/rev/8de31782da6e3f36896d6a0f06d30344aab07c23
https://hg.mozilla.org/mozilla-central/rev/8de31782da6e
Assignee | ||
Comment 8•4 years ago
|
||
Daniel, considering sec-low how far do you think it's worth to uplift this, Beta and ESR?
Reporter | ||
Comment 9•4 years ago
|
||
I think we can just fix it on Release when it gets there. We don't normally backport sec-low bugs to ESR or beta, but since it's a simple fix and Chrome has already released their version of this fix we may want to do so. But fx84 will probably get released before the Chrome bug is unhidden so we don't have to.
Updated•4 years ago
|
Comment 10•4 years ago
|
||
(In reply to Marco Bonardo [:mak] from comment #8)
Daniel, considering sec-low how far do you think it's worth to uplift this, Beta and ESR?
Marco, can you make a final decision here about which uplifts you think make sense? :-)
Assignee | ||
Comment 11•4 years ago
|
||
Comment on attachment 9182865 [details]
Bug 1661365. r=Gijs
ESR Uplift Approval Request
- If this is not a sec:{high,crit} bug, please state case for ESR consideration: while this is just a sec-low, it is a simple patch and Chrome already fixed this bug, so it may be worth picking it, it would also unify the behavior across channels.
- User impact if declined: Downloading and launching a no-name file may open a same-name exe file in the saame folder
- Fix Landed on Version:
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): It's a very simple patch
- String or UUID changes made by this patch:
Assignee | ||
Comment 12•4 years ago
|
||
I'd just go for ESR considered Chrome has a fix already, and having a different behavior across channels is annoying when debugging reports.
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 13•4 years ago
|
||
I have reproduced the reported behavior on Windows 10, on Beta v83.0b5 and verified the newly implemented behavior on Nightly v84.0a1 from 2020-10-29.
To succeed this, I have copied a random extensionless file from program files, named it notepad and uploaded it to Google Drive, while putting a notepad.exe (executable file) in the download folder. Now, after downloading the notepad extensionless file and attempting to open it from the download panel, no longer opens the .exe file, but shows the extensionless one in the folder (does not attempt to open it).
Waiting for possible uplifts.
Updated•4 years ago
|
Updated•4 years ago
|
Comment 14•4 years ago
|
||
Comment on attachment 9182865 [details]
Bug 1661365. r=Gijs
Agreed that consistency across channels makes sense here. Approved for 78.6esr.
Comment 15•4 years ago
|
||
uplift |
Updated•4 years ago
|
Comment 16•4 years ago
|
||
This fix is verified in ESR v78.6.0esr with the same method as described in comment 13.
Comment 17•4 years ago
|
||
Comment 18•4 years ago
|
||
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Updated•4 years ago
|
Comment 19•4 years ago
|
||
Did the test here ever land? Phab doesn't seem to think so.
Assignee | ||
Comment 20•4 years ago
|
||
No, I planned to land it in 89, but didn't yet.
Comment 21•4 years ago
|
||
Assignee | ||
Updated•4 years ago
|
Comment 22•4 years ago
|
||
bugherder |
Reporter | ||
Comment 23•4 years ago
|
||
changing to in-testsuite+
based on comment 21