1786188 - (CVE-2022-46875) Mozilla Firefox Download Protections were bypassed by .atloc / .ftploc files on MacOS

Status: VERIFIED FIXED

(Firefox :: File Handling, defect, P2)

Description

[SSD Secure Disclosure]

Attachment: poc.atloc

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36

Steps to reproduce:

Mozilla Firefox Download Protections were bypassed by .atloc / .ftploc files on MacOS

I have identified CVE-2021-38510 patched in 2021. Further analysis confirmed that vulnerabilities in this category have not yet been fully patched in Mozilla Firefox.

CVE-2021-38510: https://www.mozilla.org/en-US/security/advisories/mfsa2021-48/#CVE-2021-38510

The patched vulnerability outputs the following warning when downloading the executable file called inetloc.

Open Executable File?
“poc.inetloc” is an executable file. Executable files may contain viruses or other malicious code that could harm your computer. Use caution when opening this file. Are you sure you want to launch “poc.inetloc”?

However, this warning does alert not work for .atloc and .ftploc which can perform the same function, the executable will be executed. This issue can be vulnerable to arbitrary command execution.

1. Download the attachment poc.atloc / poc.ftploc.
2. There is no warning about downloading this executable file.

Actual results:

The file is downloaded without warning

Expected results:

A warning should have been given

Comment 1

[SSD Secure Disclosure]

Attachment: poc.ftploc

Comment 2

[SSD Secure Disclosure]

Attachment: demo_ftploc.mov

Comment 3

[SSD Secure Disclosure]

Attachment: Demo_atloc.mov

Comment 4

[:Gijs (he/him)]

jeez this is the bug that just won't die, isn't it.

How many of these filetypes does macOS support!? Would be useful if there was some documentation to that effect...

Dimi, do these things need adding to safebrowsing like inetloc/webloc/fileloc?

Reporter: out of interest, how did you find out about these file extensions? And does apple still block these same files from working if you use file: all-lowercase, rather than FiLe like in the attached examples?

Comment 5

[Dimi Lee [:dimi]]

(In reply to :Gijs (back August 24; he/him) from comment #4)

Dimi, do these things need adding to safebrowsing like inetloc/webloc/fileloc?

For download protection to send query to Google's service when downloading .atloc / .ftploc, the answer is yes, we'll have to add them to the list like inetloc/webloc/fileloc.
However, Chrome doesn't send ping for these two file extensions, which probably means they don't support it currently. So I think we should not add these extensions now. If this issue is also reported in Chrome and they think this is a valid issue, they might add them. We can include these extensions in our list by then.

Comment 6

[SSD Secure Disclosure]

Hi,

I saw you asked for our info, what information do you need from us?

Comment 7

[:Gijs (he/him)]

(In reply to SSD Secure Disclosure from comment #6)

Hi,

I saw you asked for our info, what information do you need from us?

It would be great if you could answer these questions:

Reporter: out of interest, how did you find out about these file extensions?

(and, are there others? Is there a list? I could not find documentation about atloc files, for instance)

And does apple still block these same files from working if you use file: all-lowercase, rather than FiLe like in the attached examples?

Comment 8

[Marco Bonardo [:mak]]

.afploc (Apple Filing protocol) should also be added here with .atloc and .ftploc, it shows the same behavior.
.mailloc, .vncloc, .nslloc, .newsloc are instead not showing the same behavior, they rely on another app to handle their contents, rather than trying to handle the file url.

This command prints a dump of the LaunchService register:
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -dump
in the dump you can search for internet-location to find all the loc extensions, they also have an il** binding (I assume short for internet location)

Comment 9

[Marco Bonardo [:mak]]

Dimi, should we still exclude fileloc and inetloc from apprep pings, considered this https://source.chromium.org/chromium/chromium/src/+/main:components/safe_browsing/content/resources/download_file_types.asciipb;l=1751-1781;drc=b6ef71f67dd1e0e591778363bd082e8870e8ee0a
Am I looking at the wrong list?

Comment 10

[Marco Bonardo [:mak]]

Attachment: Bug 1786188. r=gijs!,dimi!

Comment 11

[Marco Bonardo [:mak]]

Attachment: Bug 1786188 - test. r=gijs!

Depends on D163275

Comment 12

[Dimi Lee [:dimi]]

(In reply to Marco Bonardo [:mak] from comment #9)

Dimi, should we still exclude fileloc and inetloc from apprep pings, considered this https://source.chromium.org/chromium/chromium/src/+/main:components/safe_browsing/content/resources/download_file_types.asciipb;l=1751-1781;drc=b6ef71f67dd1e0e591778363bd082e8870e8ee0a
Am I looking at the wrong list?

Not sure if I'm mistaken, but for inetloc, it looks like we wanted to send the ping in Bug 1731779. However, the patch in the bug is not sending the ping? (because we added the extension in this list). And in bug 1744329, it seems we did plan not sending ping for fileloc?
gijs, could you help clarify what our plan was for inetloc and fileloc? thanks!

Comment 13

[Marco Bonardo [:mak]]

To clarify my patch here is removing inetloc and fileloc from kNonBinaryExecutables since I thought the reasoning was "chromium doesn't do that", but they actually do send the pings. I'm happy to put them back of course, just trying to understand the reason behind that. Are there privacy implications?

Comment 14

[:Gijs (he/him)]

(In reply to Marco Bonardo [:mak] from comment #13)

To clarify my patch here is removing inetloc and fileloc from kNonBinaryExecutables since I thought the reasoning was "chromium doesn't do that", but they actually do send the pings. I'm happy to put them back of course, just trying to understand the reason behind that. Are there privacy implications?

I think there are privacy implications to sending to apprep in general right? And we mitigate by sending hashes initially, or something. I'm not overly worried about these files vs. contents of word documents and whatnot, which also get sent to apprep by default.

Honestly I'm happy to do whatever Dimi suggests we should do for all 5 of these filetypes. There's not much detail in dveditz' comment that led to us adding fileloc, and I don't recall other context. We should make sure that if the test still has comments on which files do/don't get sent to apprep we should make sure those comments for these filetypes reflect reality.

Comment 15

[Marco Bonardo [:mak]]

I merged the test changes in the patch. While it's true we usually don't land tests along with security fixes, in this case it's not avoidable because the test checks the cpp lists. it doesn't disclose more details than the patch anyway.

Comment 16

[Marco Bonardo [:mak]]

https://hg.mozilla.org/integration/autoland/rev/165e314fa82d99dd0f7480b62c8211191d16b857

Comment 17

[Marco Bonardo [:mak]]

https://hg.mozilla.org/mozilla-central/rev/165e314fa82d99dd0f7480b62c8211191d16b857

Comment 18

[Ryan VanderMeulen [:RyanVM]]

Is this something we're going to want to uplift this cycle still?

Comment 19

[Marco Bonardo [:mak]]

Comment on attachment 9305692 [details]
Bug 1786188. r=gijs!,dimi!

Beta/Release Uplift Approval Request

• User impact if declined: sec-moderate issue, users can download crafted files on disk that when executed from firefox will open other apps on disk without showing a warning
• 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: Downloading and opening files with the .afploc, .atloc, .ftploc extensions in Firefox should show an executable file warning.
  This is similar to bug 1731779 and bug 1733775.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This is adding to our executable extensions list, that have been in use and tested for a long time.
• String changes made/needed:
• Is Android affected?: No

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: We have a fix for similar types already, this just adds other 3 to the same list.
• User impact if declined: No warning when downloading potentially executable files
• Fix Landed on Version: 109
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This is adding to our executable extensions list, that have been in use and tested for a long time.

Comment 20

[Dianna Smith [:diannaS]]

Comment on attachment 9305692 [details]
Bug 1786188. r=gijs!,dimi!

Approved for 108.0rc1

Comment 21

[Dianna Smith [:diannaS]]

https://hg.mozilla.org/releases/mozilla-beta/rev/ffba815d3768

Comment 22

[Anca Soncutean, Desktop QA]

Reproduced with Fx 109.0a1 (2022-11-23) on macOS 12.
Verified fixed (the warning is displayed) with Fx 109.0a1 (2022-12-03) and Fx 108 (threeherder build) on macOS 12.

Comment 23

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9305692 [details]
Bug 1786188. r=gijs!,dimi!

Approved for 102.6esr.

Comment 24

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr102/rev/f9180d5446f2

Comment 25

[Anca Soncutean, Desktop QA]

Verified fixed with Fx 102.6.0esr on macOS 12.

Comment 26

[Tom Ritter [:tjr]]

Attachment: advisory.txt