Trust

June 30, 2016

This is a follow-up to my guest post on the company blog. My employer graciously gave me the credit — or made me the fall guy — but it was truly a collaborative effort, and any grammatical errors are theirs.

There has been some criticism of our proposal for an Info.plist key that would allow an app to opt out of Gatekeeper Path Randomization. A few have questioned my knowledge, my sanity, my intelligence. I say to those critics, do you think the Lisan al-Gaib that stupid? Gatekeeper Path Randomization, as well as the "repackaging problem" it was intended to solve, are complex, technical, possibly esoteric subjects, so it is important not to rush to judgment based on first impressions and superficial understanding. Oh who am I kidding, this is the internet! Anyway, I'd like to offer a number of clarifications to help you see why an Info.plist key is not the worst idea since Brexit.

  1. Gatekeeper Path Randomization was not intended to protect users from malicious apps. Gatekeeper itself was intended to protect users from malicious apps, and all of the apps involved in repackaging attacks are Gatekeeper approved. Gatekeeper Path Randomization was intended to protect users from malicious files that are external to the Gatekeeper approved app.

  2. When Gatekeeper on Sierra "translocates" an app, it also allows the app to launch. The app is trusted and approved by Gatekeeper, just like it was before Sierra.

  3. Gatekeeper Path Randomization is not sandboxing. If the app was not sandboxed before translocation, then it is not sandboxed after translocation either. The point of translocation is to change the file path of the app bundle so that it is no longer at a predictable location relative to other downloaded files.

  4. Although a translocated app cannot modify its own app bundle, because it is running from a read-only disk image, a non-sandboxed translocated app still has write access to the rest of the file system, as usual, so it's not clear that a read-only disk image provides any security benefit. If I were to speculate, I assume that there was simply no reason for Apple to allow writes to a disk image that was just going to be unmounted and deleted when the app quits, so any writes would get lost in any case.

Critics of the Info.plist key proposal ask, why should we trust developers to not just add the key to every app and ignore the problem? The answer is that you can distrust developers in your own mind all you want, but the fact remains that Gatekeeper trusts the apps regardless of whether it randomizes their paths. It trusts them enough to allow the apps to launch, just like it did before Sierra, and that's a lot of trust. When you've downloaded a malicious app, just allowing the app to run is already deadly. If Apple trusts developers enough to give them Developer ID signing certs and allow their signed apps to bypass Gatekeeper, then why shouldn't Apple trust them with the Info.plist key too? Besides, there are automated tools to detect apps that load external resources, so any developer who misused the Info.plist key would stand a good chance of getting caught.

The real worry of the repackaging problem is not that developers will fail to address it. As developers become aware of it, they are addressing it. Most apps were never vulnerable to repackaging attacks in the first place, because they do not even attempt to load external resources relative to the bundle path, so an Info.plist key would simply be asserting what is already true. A small number of apps have been identified as vulnerable, and I believe that they will be fixed. The real worry is that even if the apps get fixed in new versions, the old versions of the apps are still vulnerable, and the old versions are also Gatekeeper approved, so attackers can continue to repackage those old, vulnerable versions. Apple can't simply revoke the signing certs for older versions of Xcode, Microsoft Word, and Dropbox, which are apps that have been identified as vulnerable. People still need to download and use older versions of Xcode, especially since Apple makes it so difficult nowadays to develop across multiple Mac OS versions. And of course the old versions, which are out in the wild, will not have the new Info.plist key. So some form of protection will still be necessary even if Apple supports an Info.plist key.

I respect that Apple had a difficult choice. I've been thinking a lot about it, and I'm not sure exactly what mechanism I would use to protect against the repackaging problem. Gatekeeper Path Randomization is flawed, in my opinion, but there is no ideal solution. Any alternative I can think of would also have major downsides. This is why the Info.plist key is so important. The best way to prevent any problems or breakage caused by Gatekeeper Path Randomization is to avoid it completely. And we know it's not necessary for most apps, because they aren't vulnerable to repackaging, so there should be an easy way to indicate to Gatekeeper that an app doesn't need it. It's not naive to trust developers with an Info.plist key; the whole Gatekeeper and Developer ID system is based on trust. If that trust is violated, then Apple has the ability to revoke a developer's signing cert, but thankfully the nuclear option has rarely been necessary.