Archive for November 6, 2019

Wednesday, November 6, 2019

Siri Stores Encrypted E-mails in Plain Text

Bob Gendler:

The snippets.db database is storing encrypted Apple Mail messages…completely, totally, fully — UNENCRYPTED — readable, even with Siri disabled, without requiring the private key. Most would assume that disabling Siri would stop macOS from collecting information on the user. This is a big deal. This is a big deal for governments, corporations and regular people who use encrypted email and expect the contents to be protected. Secret or top-secret information, which was sent encrypted, would be exposed via this process and database, as would trade secrets and proprietary data.

[…]

Another database, entities.db, stores records of people’s names, email, and phone numbers you’ve corresponded with. Although the phone number may not be in your contact list, data from emails such as signature blocks and forward information are stored. It’s like an address book built for you. This could be touchy, as it may allow quick and easy access to some potentially sensitive information.

[…]

For a company that prides itself on security and privacy, the lack of attention to detail on an issue like this completely and totally surprises me. […] I also have to wonder why it took 99 days for someone to know the answer on how to prevent this. All parties at Apple were alerted multiple times before writing this blog and giving an ample amount of time before I published this.

You can prevent it by going into the Siri settings and unchecking Mail. This does not remove e-mails that have already been stored in the database.

The Suggestions folder is protected from apps that haven’t been given permission, but the data is unencrypted on disk if you aren’t using FileVault.

Previously:

Update (2019-11-08): Jay Peters:

Apple tells The Verge it’s aware of the issue and says it will address it in a future software update. The company also says that only portions of emails are stored. But the fact that Apple is still somehow leaving parts of encrypted emails out in the open, when they’re explicitly supposed to be encrypted, obviously isn’t good.

Update (2020-02-06): Juli Clover:

Apple in macOS 10.15.3 quietly addressed a bug that left some of the text of encrypted emails unencrypted, reports The Verge.

See also: macOS 10.15.3.

Static Types in SwiftUI

Chris Eidhof (tweet, Hacker News):

In SwiftUI, the implementation works differently. In our stack above, SwiftUI knows the type: a vertical stack view with two subviews. During the execution of the program this type will never change — it’s a static property of the code. As such, our program will always render a vertical stack view with a text and a rectangle. When the state changes, some of the views’ properties might change, but the stack view with the two subviews will always persist.

This hard guarantee from the type system means that SwiftUI doesn’t need to do a tree diff. Instead, it only needs to look at the properties of each view, and update those on screen. Theoretically, this still involves walking the entire tree, but walking a tree has a much lower complexity than diffing a tree.

[…]

For view trees that have a variable length, SwiftUI uses ForEach. We won’t go into detail on ForEach, but SwiftUI requires you to provide either a constant range, or, if the length is truly dynamic, to use an identifier for each element you’re displaying. When the elements change, ForEach uses the identifier to uniquely identify elements during a diffing step.

[…]

An AnyView is a type-erased view, and as such, it provides no information at compile-time about what’s inside. SwiftUI will need to do more work at runtime to verify changes (as mentioned here, and here).

Hardened XPC Services Don’t Prompt

ZigZag:

Things get a bit more complicated if an attempt to access contact comes not from the application, but from its bundled XPC service, like explained in the video.

[…]

Luckily, smart folks at Apple thought of such scenarios, so macOS security subsystem (for simplicity, I will refer to it as TCC) understands that the AvatarService is trying to access contacts ON BEHALF of GitFinder application.

[…]

The application + XPC service combo build with hardened runtime fails to access contacts. Having proper sandbox entitlement defined, the XPC service requests access to contacts and passes that request to the application, just like it did before hardened runtime. However, this time around the TCC does not understand that the request comes from the XPC service on behalf of the application. Instead, it thinks the request comes from the application itself and hence checks if the application has required sandbox entitlement (AddressBook). Since the entitlement isn’t there, because the application does NOT need it at all, access to contact is denied.

[…]

The consequence of absence of absolutely unnecessary sandbox entitlement is the user consent dialog NOT being displayed at all. The user won’t even know the application would like to access contacts and the access will be permanently declined.

This probably happens for all the entitlements, not just the Contacts one. The same thing happened for a while with command-line tools on macOS 10.14 (except without the workaround). If not addressed, this will become a bigger issue in January, when the hardened runtime becomes a requirement.

Previously:

Update (2019-11-07): Felix Schwarz:

Bug: in #macOS 10.14/10.15 host apps needs to be given the same privacy entitlement as bundled XPC services - even if ONLY the XPC service needs it; eliminating THE key security benefit of sandboxed XPC services & increasing attack surface.

Apple’s Rosyna Keller says this is a feature, not a bug:

The issue here is better attribution in TCC. If App B is immediately passing data to App A, they both need the entitlement (because macOS knows you’re giving contacts to an unprivileged app).

This prevent attacks in which a malicious app asks a privileged app for private info only the latter is supposed to have access to.

I’m not convinced by this reasoning. Apparently, the requirement works this way for the TCC entitlements but not the traditional sandbox ones.

Felix Schwarz:

What if the XPC service only returns avatar images for email addresses?

In that case, a compromised GitFinder has no access to contacts data & only to those avatars for which the attacker already knows the email.

W/o separation of powers, an attacker gains unlimited access.

Update (2019-11-09): Jeff Johnson:

The sandbox allows the xpc service and the main executable to have different sandbox entitlements, which is how one can have the Contacts entitlement and the other not. In contrast, the hardened runtime depends only on the main executable of the app.

[…]

The app is still blocked unless the hardened runtime and the sandbox are in agreement. Here’s the catch: for better or worse, the hardened runtime and the sandbox use the same name for some entitlements. For example, they both use com.apple.security.personal-information.addressbook for the Contacts entitlement. As a consequence, if an app is both hardened and sandboxed, it’s impossible to give the Contacts hardened runtime entitlement to the [XPC service] without also giving the Contacts sandbox entitlement to the main executable!

I agree that the root problem for GitFinder is that the sandbox and hardened runtime use the same entitlement names for different purposes and with different inheritance rules.

In my opinion, I’m not sure that it is a problem. I don’t think the architecture of GitFinder reflects the intent behind Apple’s XPC API.

[…]

If the xpc passes Contacts info back the app, and network attackers compromise the app, then the network attackers have the Contacts info! The attackers may not have unlimited access to Contacts, but they still have some illicit access to Contacts. So you really haven’t solved the problem there.

This part I don’t agree with. I think it does make sense to use separate XPC services for privilege separation. In GitFinder’s case, the network and Contacts access are confined to separate XPC services. The app itself is isolated, so it shouldn’t get compromised. If it did, and the hardened runtime entitlements worked the same way as the sandbox, it would have only very limited access to Contacts through the XPC service, which is good.

The goal of the xpc service is not to limit the damage the app can do if it’s compromised, the goal is to prevent the app from getting compromised in the first place.

Why can’t it be both?

GitFinder:

I’ve never said it’s related to notarisation, but in my experience it IS related to hardened runtime, because app+xpc without hardened runtime worked fine, while the same app+xpc with hardened runtime fails on the very same macOS version/build.

GitFinder:

Furthermore, if it’s intentional (hence, a feature - “better attribution it TCC”) it would’ve been much easier if anyone from DTS had said that to me immediately, instead of having, like, seven months of back/forth correspondence…

GitFinder:

… with two DTS guys, including filing a bug report (and reporting bug number back to DTS), running log stream for “com.apple.TCC” while running test applications and doing other things I was asked for, just to confirm noticed behaviour.

Alas, the TCC/privacy stuff is virtually undocumented and was only discussed in a cursory manner at WWDC. So it’s not surprising that is isn’t well understood inside Apple, either.

GitFinder:

That’s actually what GitFinder is doing; its XPC service returns only image data for known email address (known from git commit) and nothing else.

GitFinder:

Forcing compromised GitFinder to get something else back from XPC service would require compromising XPC service as well. But if GitFinder (application) has contacts entitlement, then all contacts data is available right away.

GitFinder:

I have to agree with @mjtsai here and I think we “understand” the concept of “privilege separation with XPC services” the same way, but I accept I may be wrong. Anyway, there’s that video I referred to in the blog post

GitFinder:

It actually starts at about 2:25 and is related to Preview.app architecture and different pieces it consists of, each having access to only limited resources.

GitFinder:

Preview is probably chosen as an example of a know app. Anyway, this is how I thought of the whole concept: I will isolate access to contacts in a very small service, which can access contacts only…

GitFinder:

… not disk, not network. If it is compromised (somehow, anyhow), access to contacts is there, but no contacts data can be written to disk or send over the network. And as a small binary, (I hope) the number of potential security holes is much smaller that in much larger app.

Ilya Kulakov:

I think the case is that given

- App with the network entitlement
- Contained XPC service with the contacts entitlement

the system has to assume that App can access contacts too. XPC protects nothing: hijacked App it to give all the data.

My understanding is that privilege separation is still beneficial though: hijacked XPC cannot request App to give it contacts unless it is a part of the XPC connection protocol.

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

So the entitlement given to the xpc service applies directly to the xpc service. Indeed, if you enable the hardened runtime for the app target, it makes no difference. The hardened runtime of the app can neither allow nor prevent the unsigned dylib from getting loaded by the xpc service. The setting for Disable Library Validation on the app target has no effect at all on the behavior of the embedded xpc service. The xpc service hardened runtime does matter, at least for library loading.

[…]

In contrast to dyld, the Transparency, Consent, and Control (TCC) subsystem operates at the level of the app as a whole. The TCC database located at ~/Library/Application Support/com.apple.TCC/TCC.db stores a reference to an app as a bundle identifier; it doesn’t distinguish between the app’s main executable and the embedded xpc service’s executable. Thus, for the purpose of resources access, all that matters is the hardened runtime on the main executable.

Don’t Interrupt the Installation

Adam Engst:

The details vary, but all revolve around problems at boot, with complete lockups, accounts not available, current passwords not working, the login window reappearing after the user enters the password, or a crash screen after login. So far, it seems that only Macs with the T1 or T2 security chip are affected—that includes the MacBook Pro with Touch Bar (2016 and later), iMac Pro, MacBook Air (2018), and Mac mini (2018).

[…]

In the end, my advice is simply to go ahead with installing Security Update 2019-001 (Mojave), with two important caveats. First, make sure you have good backups before starting, in case the worst happens. That’s always a good plan anyway. Second, do not interrupt the installation process! It may take longer than you expect, but let it run as long as it needs.

I don’t know what I’m going to do once I get a T2 Mac because, since macOS 10.10 or so, probably 50% of my macOS updates get stuck and don’t complete the first time. I end up waiting several hours or overnight before giving up and hard resetting the Mac.

Archive Team’s Yahoo Groups Rescue Effort

Andy Baio:

For me, it took ten full days to get an email that my archive was ready to download — are they doing this by hand!? — but it appears complete: it contained a folder for every group I belonged to, each containing their own ZIP files for messages, files, and links.

[…]

The Archive Team wiki charts the rise and fall of Yahoo Groups, showing a peak in 2006, and rapid fall after that.

[…]

As you’d expect, the volunteer team of rogue archivists known as Archive Team are working hard to preserve as much of Yahoo! Groups as possible before its shutdown.

The Their initial crawl discovered nearly 1.5 million groups with public message archives that can be saved, with an estimated 2.1 billion messages between them. As of October 28, they’ve archived an astounding 1.8 billion of those public messages.

Previously:

Update (2020-01-31): Yahoo:

We have extended the deadline for Yahoo Groups and will now process ALL requests to download data that are submitted before 11:59 PM PT on Jan 31, 2020 (originally Dec 14). As long as the request meets this deadline, the content will not be deleted until the download is complete.

The Mad Programer (via Hacker News):

While Archive Team had also gotten involved right off the bat, they stated their goal to be grabbing as many public groups as possible. Whereas the fandom community wanted to ensure the survival of their groups, some of which had restricted access (were publicly visible but an invite was needed to join) or were private (not publicly visible).

The two teams worked in tandem; with Archive Team providing tools and logistics for backing up the data, and the SYG team which worked to sniff out the more obscure fandom groups and establish contacts with the restricted/private group owners.

FastScripts 2.8

Red Sweater updates one of my favorite apps:

Custom folder icons are now displayed in the FastScripts menu

FastScripts can now be quit by cmd-dragging the icon out of the menu bar

Revealing a folder from FastScripts now respects the user setting for default folder opener

Apps such as Path Finder can set the handler for the public.folder UTI to control which app will be used when an app tells the system to open a folder. FastScripts, along with other apps like BBEdit, lets you hold down the Option key to edit a script instead of running it, or Shift to reveal it in Finder. Unfortunately, the system doesn’t use the default folder opener when revealing a file. My apps check whether Path Finder is running and send it an Apple event to do that.

Catalina No Longer Caches Shared Photos Locally

Tyler Hall:

So, I looked, and, sure enough, that sharedstreams folder is gone. But where?

[…]

Ok. That’s great. It actually makes more sense to have shared photos also live inside your Photos.app library instead of somewhere random in ~/Library.

[…]

Of the 112 GB my shared albums previously took up, only 250 MB (MB!!!) are cached locally.

[…]

I don’t trust iCloud with my photos. And I’m not trying to single out Apple. I don’t trust Google Photos either. I don’t trust any cloud with my data. I love the convenience of iCloud photo sharing with friends and family and using Google Photos as a source of truth for my own family archives. But I want a backup of my data – just in case – that I’m in control of.

The option to “Download Originals to this Mac” doesn’t apply to shared photos. So you can’t back them up youself, and there’s no backup in the cloud. Not only does it no longer download the photos, but it also deleted the ones that had been downloaded by macOS 10.14.

Previously:

Copyright © 2000–2024 Michael Tsai.