1661365 - (CVE-2020-35112) Opening a downloaded extensionless file can launch a same-named executable on Windows

Status: VERIFIED FIXED

(Toolkit :: Downloads API, defect, P1)

Comment 1

[Daniel Veditz [:dveditz]]

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:

1. make a copy of notepad.exe in your download directory
2. from a website download the file notepad
3. 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

Comment 2

[Marco Bonardo [:mak]]

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

[:Gijs (he/him)]

See also bug 1652520...

Comment 4

[Marco Bonardo [:mak]]

(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

Comment 5

[Marco Bonardo [:mak]]

Attachment: Bug 1661365. r=Gijs

Comment 6

[Marco Bonardo [:mak]]

Attachment: Bug 1661365. Test. r=Gijs

Depends on D94268

Comment 7

[Sebastian Hengst [:aryx] (needinfo on intermittent or backout)]

https://hg.mozilla.org/integration/autoland/rev/8de31782da6e3f36896d6a0f06d30344aab07c23
https://hg.mozilla.org/mozilla-central/rev/8de31782da6e

Comment 8

[Marco Bonardo [:mak]]

Daniel, considering sec-low how far do you think it's worth to uplift this, Beta and ESR?

Comment 9

[Daniel Veditz [:dveditz]]

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.

Comment 10

[:Gijs (he/him)]

(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? :-)

Comment 11

[Marco Bonardo [:mak]]

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:

Comment 12

[Marco Bonardo [:mak]]

I'd just go for ESR considered Chrome has a fix already, and having a different behavior across channels is annoying when debugging reports.

Comment 13

[Bodea Daniel [:danibodea]]

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.

Comment 14

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9182865 [details]
Bug 1661365. r=Gijs

Agreed that consistency across channels makes sense here. Approved for 78.6esr.

Comment 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr78/rev/fc2be3fd6644

Comment 16

[Bodea Daniel [:danibodea]]

This fix is verified in ESR v78.6.0esr with the same method as described in comment 13.

Comment 17

[Tom Ritter [:tjr] (ni? for response to CVE/sec-approval/advisories/etc)]

Attachment: advisory.txt

Comment 18

[Tom Ritter [:tjr] (ni? for response to CVE/sec-approval/advisories/etc)]

Attachment: advisory.txt

Comment 19

[:Gijs (he/him)]

Did the test here ever land? Phab doesn't seem to think so.

Comment 20

[Marco Bonardo [:mak]]

No, I planned to land it in 89, but didn't yet.

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e350ab6d1e62
Test. r=Gijs

Comment 22

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/e350ab6d1e62

Comment 23

[Daniel Veditz [:dveditz]]

changing to in-testsuite+ based on comment 21