Closed Bug 1661365 (CVE-2020-35112) Opened 1 year ago Closed 1 year ago

Opening a downloaded extensionless file can launch a same-named executable on Windows

Categories

(Toolkit :: Downloads API, defect, P1)

Unspecified
Windows
defect

Tracking

()

VERIFIED FIXED
84 Branch
Iteration:
82.1 - Aug 24 - Sep 6
Tracking Status
firefox-esr78 84+ verified
firefox81 --- wontfix
firefox82 --- wontfix
firefox83 --- wontfix
firefox84 --- verified

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)

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

Crash Signature: 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 exec…

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.

Severity: -- → S3
Component: Downloads Panel → Downloads API
Priority: -- → P1
Product: Firefox → Toolkit

See also bug 1652520...

(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: nobody → mak
Status: NEW → ASSIGNED
Iteration: --- → 82.1 - Aug 24 - Sep 6
Attached file Bug 1661365. r=Gijs

Depends on D94268

Flags: in-testsuite?
Group: firefox-core-security → core-security-release
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 84 Branch

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

Flags: needinfo?(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.

Flags: needinfo?(dveditz)
Flags: qe-verify+
Whiteboard: [keep hidden while chrome bug is] → [keep hidden while chrome bug is][post-critsmash-triage]

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

Flags: needinfo?(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:
Flags: needinfo?(mak)
Attachment #9182865 - Flags: approval-mozilla-esr78?

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

QA Whiteboard: [qa-triaged]

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.

Status: RESOLVED → VERIFIED
Flags: needinfo?(daniel.bodea)
Flags: needinfo?(daniel.bodea)

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

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

Attachment #9182865 - Flags: approval-mozilla-esr78? → approval-mozilla-esr78+
Whiteboard: [keep hidden while chrome bug is][post-critsmash-triage] → [keep hidden while chrome bug is][post-critsmash-triage][adv-main84+]

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

Flags: qe-verify+
Whiteboard: [keep hidden while chrome bug is][post-critsmash-triage][adv-main84+] → [keep hidden while chrome bug is][post-critsmash-triage][adv-main84+][adv-esr78.6+]
Group: core-security-release

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

Flags: needinfo?(mak)

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

Flags: needinfo?(mak)

changing to in-testsuite+ based on comment 21

Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.