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•8 months 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•8 months 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•8 months ago
|
||
See also bug 1652520...
Assignee | ||
Comment 4•8 months 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•8 months ago
|
Assignee | ||
Comment 5•6 months ago
|
||
Assignee | ||
Comment 6•6 months ago
|
||
Depends on D94268
Assignee | ||
Updated•6 months ago
|
https://hg.mozilla.org/integration/autoland/rev/8de31782da6e3f36896d6a0f06d30344aab07c23
https://hg.mozilla.org/mozilla-central/rev/8de31782da6e
Assignee | ||
Comment 8•6 months ago
|
||
Daniel, considering sec-low how far do you think it's worth to uplift this, Beta and ESR?
Reporter | ||
Comment 9•6 months 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•6 months ago
|
Comment 10•6 months 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•6 months 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•6 months 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•6 months ago
|
Updated•6 months ago
|
Comment 13•6 months 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•6 months ago
|
Updated•6 months ago
|
Comment 14•5 months ago
|
||
Comment on attachment 9182865 [details]
Bug 1661365. r=Gijs
Agreed that consistency across channels makes sense here. Approved for 78.6esr.
Comment 15•5 months ago
|
||
uplift |
Updated•4 months ago
|
Comment 16•4 months ago
|
||
This fix is verified in ESR v78.6.0esr with the same method as described in comment 13.
Comment 18•4 months ago
|
||
Updated•4 months ago
|
Updated•4 months ago
|
Reporter | ||
Updated•13 days ago
|
Comment 19•13 days ago
|
||
Did the test here ever land? Phab doesn't seem to think so.
Assignee | ||
Comment 20•12 days ago
|
||
No, I planned to land it in 89, but didn't yet.
Comment 21•12 days ago
|
||
Pushed by mak77@bonardo.net: https://hg.mozilla.org/integration/autoland/rev/e350ab6d1e62 Test. r=Gijs
Assignee | ||
Updated•12 days ago
|
Comment 22•11 days ago
|
||
bugherder |