Posted By Rogue Amoeba Alumni on June 29th, 2016

At their recent Worldwide Developers Conference, Apple announced macOS 10.12 (Sierra), the next major version of the Mac operating system. Sierra is scheduled for official release in the fall, and we’re hard at work on getting our software ready for it. For now, however, we recommend that if you can’t live without our software — which we love to hear! — you should stick with 10.11 (El Capitan) or lower. We’ll be releasing fully compatible updates for 10.12 as soon as possible. For more detailed information, please see our Status page.

I’d like to take a few minutes now to talk directly to fellow software developers about Sierra, specifically about a new Sierra security feature called “Gatekeeper Path Randomization” (GPR) that has serious implications for software delivered outside of the Mac App Store. GPR is explained in the WWDC session video “What’s New in Security”, which you can view at https://developer.apple.com/videos/play/wwdc2016/706/.¹

As you’re likely aware, Gatekeeper is a security feature that has already been in place for several years. When enabled, Gatekeeper checks whether an app downloaded from the internet has been signed with a Developer ID certificate, which third-party developers such as Rogue Amoeba purchase from Apple. If the app is Developer ID-signed, then Gatekeeper allows the app to launch. If the app is not signed, then Gatekeeper will refuse to launch the app.

Last year, security researcher Patrick Wardle discovered a vulnerability in Gatekeeper called dylib hijacking. Wardle determined that if a Developer ID-signed app loads resources external to its app bundle via a relative file path, an attacker could package the app together with malicious external resources in order to work around the Gatekeeper protection. The app would pass the Gatekeeper check and be allowed to launch, after which it would load the malicious external resources. Wardle found that a number of popular apps, including some of Apple’s own apps, could be used as a vector for such an attack.

Gatekeeper Path Randomization is an attempt to avoid this vulnerability. It works by mounting a read-only disk image in a temporary path in the file system, copying the app onto that disk image, then launching the app from there. With the app bundle’s path thus changed, it will no longer find any external resources where it was expecting them, and thus the loading of malicious resources is prevented. For a more detailed technical analysis of GPR, as well as an investigation into some possible flaws in its implementation, see this series of more detailed blog posts I wrote elsewhere: App Translocation, Zero Day?, Undo.

The problem with Gatekeeper Path Randomization is that copying applications to a read-only disk image will break functionality in many, if not most, existing applications. Perhaps most notable, features like automatic software updates (via Sparkle or similar mechanisms) will no longer work. Apple may not view this as an issue, given that GPR will be disabled once the user moves the application out of the Downloads folder. However, many users run applications from the Downloads folder, never moving them. This is especially common when a user is trying out an application prior to purchasing it, and an app that doesn’t work as expected due to GPR seems certain to lead to lost sales. Worse, even if the customer moves your app to their Applications folder, it may continue to be broken, depending on how your app is packaged.²

We hope that Apple will make some small changes to avoid this unwelcome situation for our mutual customers. Because the vast majority of apps do not load external resources relative to the app bundle path, only a very small percentage of apps are vulnerable to the attack that Gatekeeper Path Randomization is attempting to prevent. Nevertheless, Apple’s current implementation for GPR affects all apps outside the Mac App Store, and the negative impacts will be felt far and wide. While we believe there are several changes Apple can and should make, a simple workaround would be to allow software developers to opt out of Gatekeeper Path Randomization. If an app does not load external app-relative resources, GPR provides no benefit. The app should thus be able to put a key in its Info.plist specifying that GPR should not apply to the app.³ We have filed a request with Apple to provide such a key (Radar #27018815 – “10.12 (16A201w) Apps need an Info.plist key to avoid Gatekeeper Path Randomization”), and encourage other developers to duplicate this Radar.

We support Apple’s efforts to increase security for all users on MacOS. However, this specific change will have a great deal of negative impact, while providing no security gain for the vast majority of apps. Users will be stuck with apps that don’t work (or update) as expected. The simple change we’ve proposed would still provide Apple with the desired security benefits, while removing the downside this will cause for users. We encourage you to test your software on 10.12 for possible problems, then file your own Radar with Apple detailing how Gatekeeper Path Randomization impacts your software.

Footnotes:

1. No login or developer account is required to watch the video; the information is available to the public. ↩︎

2. For example, we ship Airfoil in a folder together with Airfoil Satellite. If you move that folder from Downloads to Applications, Gatekeeper Path Randomization will still be active. ↩︎

3. The standard code-signing required for Gatekeeper would of course ensure that this flag couldn’t be tampered with. ↩︎