Hacking macOS apps with a single “.terminal” file.

A story about macOS File Quarantine, 10-year old bug, privileged OneDrive entitlements and UX security.

Vladimir Metnew
9 min readJul 27, 2020

Popular macOS apps with a file-sharing functionality didn’t delegate file quarantine to OS leading to File Quarantine bypass (Windows MOTW analogue) for downloaded files. The vulnerability has low/moderate impact, but it can be combined with other custom behaviours, and UX features to increase the severity.

Many popular products like Keybase, Slack, Skype, Signal, Telegram decided to fix the issue, but the vulnerability remains unfixed in file-syncing apps: Dropbox, OneDrive, Google Drive, etc. Overall, this vulnerability has affected at least 20+ apps, a significant part of the macOS ecosystem.

Apps from AppStore aren’t vulnerable to File Quarantine issues unless it’s OneDrive, which we’ll discuss later in this post.

During the research, I also discovered two “insecure features” in macOS: dangerous handling of .fileloc and .url shortcut files, those allow executing arbitrary local files by the full path at shortcut file opening. This behaviour allowed me to discover two Chrome and Firefox bugs: CVE-2020–6797, CVE-2020–6402

See slides for my talk on “Objective by The Sea v3” conference about File Quarantine issues.

General Attack Scenario

  1. A macOS user downloads and opens a hello.terminal file received through the application.
  2. The user expects the downloaded file is quarantined and is tracked by Gatekeeper.
  3. The application neither delegates file quarantine process to OS, nor does it on its own.
  4. Boom! Malicious code executes on the device.

UX Security

You may notice that the scenario relies on user interaction and requires convincing the user to open the file with phishing. Unfortunately, the state of UX security in many chat apps is pretty bad, and it significantly increases risks for users.

Some apps allow executing the malicious file in a single click on the file icon. For example, previous versions of Telegram has been downloading files automatically, without user consent.

It’s funny that no one takes iMessage as a good example of secure file handling. iMessage shows the QuickLook preview of the file, instead of opening it.

Another problem is that some product developers reject to think of secure file handling as a developer responsibility and shift security risks to users. (Such was a response from WhatsApp, for example).

.terminal > GateKeeper

.terminal file is not widely known. It’s a Terminal.app configuration profile and it doesn’t require +x file permission to execute a malicious payload on the device.

How to fix it?

Implementing a fix for this issue might be tricky because there are two possible options:

  1. Quarantine the downloaded file with xattr utility — set com.apple.quarantine attribute to a specific value (setting an arbitrary value also works). For example, Signal for macOS implements this option.
  2. Delegate quarantine to OS in Info.plist: OS will quarantine all files downloaded by this application. This approach is tricky, because OS may quarantine the new version of the app downloaded by the auto-update mechanism. For example, Brave browser had this issue in the past.

Chat apps are safe now

Overall, I sent around ~15 reports about file quarantine to different chat apps, messengers, and mail apps.

Attacking file-syncing apps

Most file-syncing apps sync files without quarantine attribute.
In the case with file-syncing apps, the idea behind the attack scenario is to sync [1] the file into the user’s cloud file storage and later “somehow” launch [2] the synced file on the user’s device.

In my opinion, the most interesting approach to “syncing” is to leverage App Folder integrations, that users can authorize via OAuth.

Imagine, an attacker somehow hacks a file convertor and steals OAuth tokens.
At this point, the attacker can sync anything to all machines owned by users who authorized the hacked OAuth app to write into their cloud folders. And these malicious files won’t have a quarantine attribute, once they’re synced to the device.

The attacker still needs an inconspicuous way to execute the synced file on the device to bring minimal user attention. There is an option for that — .url shortcut file that can launch any file on the device by its full path.

.fileloc file aka a bug that wasn’t patched in 10 years

When Apple fixed .url file handling in Catalina, I started searching for a bypass and eventually found mentions of .fileloc file.

The dangerous nature of .fileloc has been known since 2009:

Incomplete blacklist vulnerability in Launch Services in Apple Mac OS X 10.5.8 allows user-assisted remote attackers to execute arbitrary code via a .fileloc file, which does not trigger a “potentially unsafe” warning message in the Quarantine feature.

*10years-bug
  • .fileloc still works on Catalina. Means, Apple doesn’t consider this feature to be a bug in macOS.
  • Apple knows that it’s possible to execute files on the device with .fileloc. Apple also knows that all default apps have quarantine enabled.
  • Launching a quarantined file with .fileloc doesn’t have security risks, because the user will be asked to confirm file launching.
  • That means, .fileloc is not a vulnerability by itself unless there are files without a quarantine attribute.

Here is a sample .fileloc file.

.fileloc in browsers

  1. Chrome and Firefox didn’t have .fileloc in their safebrowsing blocklists.
  2. Thus, a browser extension with downloads permission could execute arbitrary files on the device.

CVE-2020–6797, CVE-2020–6402

PoC screencast:

Dropbox

I think Dropbox was aware of this issue for a long time, but they decided to leave this this unpatched, because the patch impacts UX (leading to fewer users and profits, consequently).

OneDrive

OneDrive is distributed on AppStore. But it doesn’t apply quarantine to the synced files. Why?

“However, when an app such as TextEdit with the “com.apple.security.files.user-selected.executable” entitlement saves a file, it removes the quarantine extended attribute!”

OneDrive removes quarantine meta-attribute because Apple granted itcom.apple.security.files.user-selected.executable entitlement.

Here is MSRS’s response about file quarantine in OneDrive:

The ask is for a mark-of-the-web (MOTW) to be attached to files that OneDrive syncs. We do not do this on either Windows or the Mac. On the Mac, attaching a quarantine/MOTW bit has a bunch of user experience impacts that break features like Files on Demand and in general are inappropriate for a sync client.

At one point, the Mac store app had the quarantine bit set on files automatically by the system because it was sandboxed. This broke the aforementioned items. We asked for (and received) an exception from Apple’s head of macOS security to set an entitlement that does not cause the quarantine bit to be set. Apple’s position is generally that sync apps do not need to have MOTW/quarantine set on synced content.

According to MSRC:

  1. Quarantine dialogs break UX.
  2. Apple “legitimately” granted OneDrive those entitlements.
  3. Apple’s head of macOS security made an exception for OneDrive 😯.
    In my opinion, this case is pretty similar to “Hey vs Apple” case. When big companies can obtain some specific permissions ignoring general platform rules.
  4. “Apple’s position is generally that sync apps do not need to have MOTW”.
    At the same time, Apple’s iCloud applies quarantine meta-attribute to synced files
    🙃
Microsoft: Hey Apple, we lose $PROFIT per year due to Quarantine dialogs. Do you have a hack for this?
Apple: Sure, apply these entitlements.
Microsoft: Cool.

Conclusions:

  1. Both TCC and Quarantine impact macOS UX heavily. Product companies don’t want to implement OS security features because it impacts their growth and profits.
  2. Apple is aware of .fileloc and implements secure file handling in default apps. At the same time, Apple grants entitlements to AppStore apps (OneDrive) to bypass quarantine. That makes .fileloc a security threat again.

Also, Microsoft historically has issues with secure file handling in their products. It’s easy to prove by checking Chrome SafeBrowsing rules. You’ll notice that most “DANGEROUS” executable file types belong to Windows.

Microsoft response to my report about quarantine issues in Skype was like: “ok, nice, bye. We will fix it”. No HoF, no bounty, no thanks.

Response from bug hunters

A few H1 reports about file quarantine reported by bug bounty hunters.

When my reports to Brave Browser and Keybase were disclosed, I’ve noticed that bug hunters started reporting file quarantine issues to other macOS apps. Previously, I haven’t seen any mention of this technique on bug bounty programs.

I want to say “Mahalo!” to these hunters for making macOS apps more secure. This also proves the vulnerability is easy to understand and reproduce.

Also, I received thanks from bug hunters for making this technique public.
I’m happy that my work helps other people!

Big Sur = the end of .terminal epoch

Assuming there are no similar files like .terminal, asking for a user confirmation upon file opening is a good way to prevent further abuses of .terminal. Nice fix, Apple.

See the full list of files recognized by macOS in the slides.

Open Questions

  • Who should be responsible for secure file handling? Developers, platforms or users?
  • What’s the best way to engage companies to implement security features?
  • Is it acceptable to make “exceptions” for some companies?
  • Is it a unique case in the Apple ecosystem?
  • Is there a way to fix all problem with file quarantine? Do we need to solve them?

Try to search for misconfigurations when researching macOS/iOS apps. (SMJobBless is also a good evidence of this theory)

You can find more PoC screencasts in the slides.

Slack

Report on HackerOne.

Keybase

Repost on HackerOne.

Keybase Team is awesome, they quickly responded to the request and awarded a good bounty. Quarantine was added to both macOS/Windows Keybase apps and most importantly to Keybase FileSystem (KBFS). I want to thank Keybase team for effective collaboration!

Telegram

Another Telegram bug

Telegram for macOS allowed users to send links pointing to file:// origin. By combining this behaviour with insecure link opening (NSWorkspace.openURL), the attacker could send a crafted link opening of which would lead to code execution on the device.

Yes, it’s the same bug as in Zoom.

PoC was: file://host/Applications/Calculator.app/Contents/MacOS/Calculator

References

  1. https://lapcatsoftware.com/articles/notarization.html
  2. https://eclecticlight.co/2019/04/26/%F0%9F%8E%97-quarantine-documents/
  3. https://eclecticlight.co/2019/05/10/finder-security-errors-opening-documents-a-summary/
  4. https://blog.malwarebytes.com/cybercrime/2015/10/bypassing-apples-gatekeeper/

Thanks

  • Mahalo to “Objective by the Sea” for inviting me to this awesome conference!
  • Thanks to authors of public resources about macOS security for sharing knowledge with others.
  • Thanks to “hackers” who were open to discussing abovementioned vulnerabilities, behaviours and design decisions.

P.S.

As you see, File Quarantine is a huge subject for discussion that involves many different parties (security folks, end-users, product managers, platforms). File sharing is basic functionality that significantly impacts end-users. Obviously, any change to this functionality should be carefully examined by all involved parties.

I try to treat this post as a summary of my research, that I was (asynchronously) doing for a long time. Right now I feel like I see the logical end of this problem. I don’t try to convince others to think that Quarantine should be enabled/disabled/changed.

--

--