Airfoil
Audio Hijack
Farrago
Fission
Loopback
Piezo
Soundsource
Sierra and Gatekeeper Path Randomization
Posted By Jeff Johnson 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/.1
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.2
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.3 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:
-
No login or developer account is required to watch the video; the information is available to the public. ↩︎
-
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. ↩︎
-
The standard code-signing required for Gatekeeper would of course ensure that this flag couldn’t be tampered with. ↩︎
Dmytro says:
June 29th, 2016 at 12:06 pmTo avoid GPR you need to place all your signed bundles and external resources to a DMG image and sign that image using codesign utility with your Developer ID certificate.
Paul Kafasis says:
June 29th, 2016 at 12:22 pm@Dmytro: Signed disk images are an alternate workaround for this issue, but they are not an appealing one. The simplicity of zip archives is greatly appreciated, and they have proven to be less confusing for users. Using a disk image for distribution places an unnecessary burden on the user, and having switched away from disk images several years ago, we’re loathe to return to them simply to work around Apple’s issues.
SupportTech says:
June 29th, 2016 at 1:29 pmFor what it’s worth: All of our staff (4,000+) have Open Safe Files after Downloading turned off as as security precaution.
In that case wouldn’t .zip function exactly like .dmg ? Both leave the archive untouched in Downloads and require the user to do something.
Greg says:
June 29th, 2016 at 4:27 pmWhy don’t you just create a standard Apple installer package for your software. Users know how to use them to install software; and Sierra will even help the user clean up the no-longer needed package after install.
Oliver says:
June 29th, 2016 at 5:23 pmI go with Greg. An installer should easily solve this.
Vince says:
June 29th, 2016 at 6:13 pmYou’re not working around Apple’s issues, your working around your issues you’ve created by using zips instead of a standard DMG installer. A zip is not simpler; having the DMG do the work for the user is simpler (I dislike apps that use zips and make me do their work for them). This is a problem of your own making, and fixing it is simple indeed. Use an installer.
Seriously? says:
June 29th, 2016 at 7:26 pmNot sure if a DMG or an installer is a better solution, but surely you cannot be serious that developers should be allowed to opt out of a safety feature designed to protect users from developers? I mean, is that an April Fools’ Joke?
Anon says:
June 29th, 2016 at 7:59 pm1. Many Mac users hate package installers. A good number of users & developers (including the author) also think DMG’s provide not a great user experience as well.
2. Apple seems to be OK with opting out of this safety feature if a developer uses a signed dmg. Presumably, that would make the dev competent enough, so an info.plist key wouldn’t be out of the question either.
Peter N Lewis says:
June 29th, 2016 at 9:26 pmLots of users hate installers – for one thing it immediately muddies the water as to how to get rid of this thing, and as to what else it might be doing to the system.
A zip file requires a simple double click and then off you go – who cares if the application is in the Applications folder or the Downloads folder, that’s up to the user. Some apps have put up an alert asking or offering to move the app to the Applications folder – this is completely unnecessary for any well behaved application… until now. Now it has become a necessity or version updates will not work.
A DMG is a terrible solution because users double click the DMG, then run the application, and then later the application has disappeared and they have no idea why. This is the reason many of us have chosen to distribute .zip archives in the first place!
And yes, I agree, there is absolutely zero chance of Apple allowing a plist entry to disable this feature as developers would simply turn on the plist entry without any consideration of the consequence.
Rosyna says:
June 29th, 2016 at 9:27 pmJust created a signed zip archive. Then you get all the benefits of zip along with the benefits of code signing. See the xip man page for more information.
xip archives work back to Mac OS X 10.6. Xcode 8.0 betas are shipped as xip.
Anon says:
June 29th, 2016 at 9:59 pm@Rosyna I am pretty certain xip files have no effect on gatekeeper randomization / app translocation. I don’t think this is a mistake on Apple’s part either. I don’t think they will advocate xip very strongly, at least not for final releases.
Paul Kafasis says:
June 29th, 2016 at 10:19 pm@SupportTech: If Open Safe Files is off, they’re closer, but .dmg is still messier. We’ve seen many users who run apps off .dmgs, and keep the .dmg around, forever (mounting it every time). That doesn’t happen with .zip.
@Greg, @Oliver: As others have noted, installers have many issues. Being required to run an installer is a deterrent for anyone trialing an app, for starters.
@Vince: .dmgs are not at all the “standard”. .zip is more prevalent, and we’ve found it to be far simpler for users. We’ve distributed via both .dmg and .zip, and with a sample size of tens of thousands of users, .zip is much more preferable.
As for an installer, see the above note.
@Seriously?: This safety feature provides literally no protection from apps which do not load external resources. Developers should absolutely be able to opt out of it (or better yet, Apple should implement a better solution to the problem, which affects a tiny percentage of apps).
@Anon: Indeed! Thanks.
@Peter N Lewis: Spot on on all points regarding installers and .dmg. As for the plist entry, it would require an active effort by developers to turn it on. That same effort could/should be applied to securing any insecure app. There may be a low likelihood of this happening, but it’s worth a shot. Frankly, we’d prefer they scrapped this poor implementation, and went back to the drawing board, but this is an easy workaround that still provides benefit against vulnerable apps that are already out there.
@Rosyna: What we’ve found matches what @Anon has found – .xip doesn’t seem to solve the issue in our tests. You’ll also note that Apple doesn’t mention xips in its code signing tech note. Perhaps our tests were incorrect? But with nearly non-existent documentation on .xip, it’s tough to tell. It’s also not a stellar solution, as it would require updating Sparkle to understand .xips.
Anon says:
June 29th, 2016 at 10:40 pm@Paul – If you decide to ship dmg’s in the end, note you can still feed zip’s to Sparkle (might be more efficient as a bonus). The archive format for initial distribution and updating doesn’t have to be the same (hence Sparkle does not *have* to understand ). The quarantine is removed in the update process, avoiding translocation and other stuff.
George says:
June 29th, 2016 at 11:28 pmI personally don’t like apps bundled in zips. I love .dmg. Firstly, I like how Apple tries to create some sort of uniformity. Why shouldn’t all apps be installed into the apps folder. It’s where they should be. What’s the big deal. And what kind of a moron runs the app every time from the dmg image? Just provide proper instructions. Installers are fine. Just make it clear to the user how to uninstall if they want to get rid of it. You can put those instructions right into the installer window as the app is installing. Just use some common sense. Do you think poisonous materials shouldn’t be stored in containers because some people don’t read the labels? Just stfu and solve your problem. If people are too stupid to do things right, provided you gave them EVERY opportunity to understand what they’re doing, screw em.
John says:
June 30th, 2016 at 8:31 amHmm, I wonder about a flag instead for .dmg files that would extract the contents on open, similar to .zip files.
I think there is a difference between a flag in the Info.plist file (intention) and a signed disk image. The first means that any app with the flag is still vulnerable to being repackaged with malicious external resources. The second means that the contents can’t be modified without resigning, reducing the attack surface to having a valid developer certificate. (Unless a signed disk image requires the same certificate as the app inside.)
So some sort of flag (or hidden file in the image, to avoid changing the disk image format) in order for the open action to be changed to automatically extract the contents would give the same user experience as a .zip file currently does but still enforces the security policy on the app contained within.
I don’t develop apps, so I don’t have any experience here. But it seems to address the core problem, wouldn’t it? Or is it more, where even apps dragged out from a signed disk image still get GPR enforcement as long as they’re executed outside of “/Applications”?
Charlien says:
June 30th, 2016 at 12:20 pmAs a USER, not a developer, I want the option to turn off the individual security methods at my discretion. I don’t keep applications in the /Applications directory unless they absolutely won’t run anywhere else. I do run apps from dmg’s when I only use them on rare occasions. Before running any installer, I examine it using Pacifist. Not all developers of apps can afford the Apple cert. Not all developers want to go through the App Store. I endorse macOS being shipped with maximum security turned on. But I reserve the right to selectively turn it off while accepting the consequences of my actions. I don’t use iOS devices because of this. And if macOS closes all pathways to users being innovative in their software designs, then I will be queuing up a version of Linux.
Paul Kafasis says:
June 30th, 2016 at 3:39 pm@Anon: Indeed, but that possible switch to .dmg itself is problematic, as discussed above.
George: The big deal is we believe it’s good to provide users with options, as well as the freedom to use their own machine however they like. As for “installers are fine”, if only stating it made it so. However, a couple decades of experience have made it quite clear that installers are far from ideal for distributing software. We prefer not to say “screw ’em” to any of our customers, even those who aren’t as technically inclined. Providing instructions and uninstallers is simply not as effective, nor as user-friendly as a zipped package application.
As for “s-ing” “tfu”, well, no. We’re attempting to improve upon the current situation for ourselves, for other developers, for users, and even for Apple. A poor implementation of this attempt at improving security is likely to be worse, and more problematic, than doing nothing at all. We’re hoping to avoid that.
@John: Ultimately, that boils down to changing .dmg to act like .zip. That’s a nice enough idea, but it’s not something we can do on our end.
@Charlien: We definitely support users having control over their own machines. The locked-down nature of iOS has been a turn-off for us as developers as well.
Chris Campbell says:
June 30th, 2016 at 11:30 pmThe primary problem that Apple is trying to solve: a code-signed app using non-signed resources outside the app wrapper is an open vector for security attacks.
Disk images and Installer packages allow the developer to code-sign the entire distribution asset, which prevents it from being tampered with. Which isn’t the case with .zip or any other archives. At best, the developer can publish a checksum somewhere and hope that users find it, calculate the checksum themselves, and discard the .zip if the computed checksum doesn’t match. Which isn’t nearly as secure as what can be implemented using disk images or Installer packages.
It would be great if Apple would extend .zip to implement similar features, but if they already have other technologies that solve the problem, I’d rather them spend their time elsewhere.
John says:
July 1st, 2016 at 7:56 am@Paul: That’s what I figured. ;-) I was thinking that perhaps requesting the changes I mentioned might be more palatable to Apple than a flag in Info.plist. An extension to the disk image format (proprietary, and under Apple’s control) or adding a hidden file (which could be ignored by older versions of OS X / Gatekeeper) seems like it’d be less invasive.
Not that I’m particularly concerned about political correctness! I’m just thinking of ways that could address the use case you outlined in a way that might be more likely to get accepted/implemented.
In any case, I agree with you. As a user who always drags his apps into “/Applications”, I still recognize that many users don’t. Packaging apps as special directories is elegant, and it’d be a shame to lose the flexibility of launching them from anywhere in the file system.
Steve says:
July 1st, 2016 at 8:36 pmAs a longtime user of Linux and OS X I absolutely love iOS and how secure it is. I stopped having to think or worry about installing apps. They are just simply safe. I guess after being an administrator for so long I like being able to just switch off my brain.