Closed Bug 1786188 (CVE-2022-46875) Opened 2 years ago Closed 1 year ago

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

Categories

(Firefox :: File Handling, defect, P2)

Firefox 106
defect

Tracking

()

VERIFIED FIXED
109 Branch
Tracking Status
firefox-esr102 108+ verified
firefox107 --- wontfix
firefox108 + verified
firefox109 + verified

People

(Reporter: contact, Assigned: mak)

References

Details

(Keywords: csectype-priv-escalation, sec-moderate, sec-vector, Whiteboard: [adv-main108+][adv-esr102.6+])

Attachments

(6 files, 1 obsolete file)

Attached file 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

Attached file poc.ftploc
Attached video demo_ftploc.mov
Attached video Demo_atloc.mov
See Also: → CVE-2021-38510
Component: Untriaged → File Handling

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?

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(dlee)
Flags: needinfo?(contact)

(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.

Flags: needinfo?(dlee)

Hi,

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

Flags: needinfo?(contact)

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

Flags: needinfo?(contact)
Assignee: nobody → mak
Severity: -- → S3
Priority: -- → P2

.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)

Flags: needinfo?(dlee)
Attached file Bug 1786188 - test. r=gijs! (obsolete) —

Depends on D163275

(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!

Flags: needinfo?(dlee) → needinfo?(gijskruitbosch+bugs)

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?

(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.

Flags: needinfo?(gijskruitbosch+bugs)
Attachment #9305693 - Attachment is obsolete: true

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.

Status: NEW → RESOLVED
Closed: 1 year ago
Flags: needinfo?(contact)
Resolution: --- → FIXED
Target Milestone: --- → 109 Branch

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

Group: firefox-core-security → core-security-release
Flags: needinfo?(mak)
Flags: in-testsuite+

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.
Flags: needinfo?(mak)
Attachment #9305692 - Flags: approval-mozilla-esr102?
Attachment #9305692 - Flags: approval-mozilla-beta?
Flags: qe-verify+

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

Approved for 108.0rc1

Attachment #9305692 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [qa-triaged]

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 on attachment 9305692 [details]
Bug 1786188. r=gijs!,dimi!

Approved for 102.6esr.

Attachment #9305692 - Flags: approval-mozilla-esr102? → approval-mozilla-esr102+

Verified fixed with Fx 102.6.0esr on macOS 12.

Status: RESOLVED → VERIFIED
Whiteboard: [adv-main108+]
Whiteboard: [adv-main108+] → [adv-main108+][adv-esr102.6+]
Alias: CVE-2022-46875
See Also: → 1816132
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: