Archive for December 18, 2019

Wednesday, December 18, 2019

Persistent File Access via com.apple.macl Xattr

Jeff Johnson (Hacker News):

I’ve discovered that on Catalina, pasting a file from Finder not only outputs the file path in Terminal, it also invisibly and permanently grants Terminal access to the file, bypassing any macOS privacy protections!

[…]

Notice that after copying from Finder, the Documents folder has a new com.apple.macl extended attribute. (I’ll assume the “l” in “macl” stands for “lockdown” until someone tells me otherwise.) This special extended attribute gives Terminal (and possibly other apps?) special access to the file. The com.apple.macl extended attribute, as well as the special file access, is persistent across reboots. Indeed, it remains even if you reset the privacy permissions of Terminal!

The com.apple.macl extended attribute is so persistent that you can’t even delete it.

Unless you turn off System Integrity Protection. This seems so much more convenient than the way it works for sandboxed apps, where the app is responsible for storing and using a security-scoped bookmark.

See also: Quinn the Eskimo.

Update (2019-12-19): Rosyna Keller:

Indeed, this was documented in the Advances in macOS Security session at WWDC. To prevent spurious dialogs when a file access is clearly due to a user action (like dragon drop/manual file opens, double-click in the finder) access is inferred by the user’s action and granted.

I watched that session and don’t think it really conveyed what is going on:

And user privacy protections in macOS Catalina now support the notion of user intent, when-- which is inferred when double clicking on files in Finder, when dragging and dropping from another application or when selecting files in an Open or Save panel.

And when the user performs any of these actions, the file-- performing any of these actions on a file protected location, your app gets access to the file or files that the user selected without the need for a consent prompt. So let’s see how Catalina’s inference of user intent compares with user consent. Sorry. So, first of all, user consent is reactive. Access may be granted only after your app tries to read or write a file, whereas user intent is proactive. Access is granted before the app, even tries to read or write the file. And user consent prompts to kind of interrupt the user’s workflow, whereas user intent is inferred from standard UI interactions. In order to minimize those interruptions, user consent applies to an entire class of data, for example, all files on your desktop.

Whereas user intent is inferred for just the file or files that the user is interacting with.

Jeff Johnson:

As developers, we need to test our software under known conditions. That’s when all these inscrutable irrevocable privacy protection exceptions become a nightmare. tccutil reset was good enough on Mojave, but now it’s not on Catalina. Apple offers no good solution to the problem.

Update (2019-12-20): Howard Oakley:

The com.apple.macl xattr contains a list of UUIDs for the apps which can open it, each with a prefix 0100 containing a single flag which presumably grants that file-specific entitlement. There can be one or several UUIDs, which are stored there in binary, not text[…]

[…]

There are some worrying features in Catalina, though. I have written before about the promiscuous use of the quarantine flag on documents in Mojave and earlier. I regret to report that this behaviour doesn’t appear to have changed at all, and in many current Catalina installations the new com.apple.macl xattr will be outnumbered by all those devalued quarantine flags. This also gives rise to some strange consequences: open a PDF in Preview without saving it, and it will be given a quarantine flag but no com.apple.macl xattr. If you try to Save that to overwrite the original document, Preview promptly refuses, and may not even be able to write that file out under another name. Repeat that with a PNG file, and Preview has no such problems.

Previously:

Jeff Johnson:

At least with the quarantine xattr, the value contains the bundle id of the app that wrote it. The macl is effectively untraceable.

Update (2019-12-26): Jeff Johnson:

I received a link to a video from the PSU Mac Admins conference in August that mentioned the macl xattr I blogged about recently.

Not much new info on that subject, but relatedly, the speaker said the quarantine xattr may apply to curl in the future!

Abusing Electron Apps to Bypass macOS’s Security Controls

Wojciech Reguła (via Patrick Wardle):

To bypass the Transparency, Consent, and Control service (TCC), we need an Electron application that already has some privacy permissions. As it turns out, you probably have at least one such app installed - look, for example, on your desktop messengers.

[…]

To do this, we have to recall how Electron apps work. Simplifying, the main executable (that is signed with the entitlements and hardened) is responsible for loading the HTML, JS and CSS files and render them. So the actual program’s logic is stored in these files, not in the signed executable!

[…]

What surprised me, the modified applications still have access to their entries in the Keychain - so these entries can be stolen as well.

Rewound Rejected From the App Store

Jay Peters (MacRumors):

Rewound, the basic music player app released last week that you could skin to make your iPhone look remarkably like an iPod Classic, has been pulled from the App Store, according to Rewound blog post published on Medium.

Rewound:

Rewound was specifically designed not to infringe on Apple’s trademarks and we didn’t. Rewound could look many ways. Not until users started sharing/using clickwheel skins did they ban the app.

[…]

Skins were user added/downloaded, we didn’t include them in the app.

If the iPod skin wasn’t built-in and wasn’t provided by the developer, I don’t see what the issue is.