10.12 (16A201w) Apps need an Info.plist key to avoid Gatekeeper Path Randomization

Originator:Paul.Kafasis
Number:rdar://27018815 Date Originated:2016-06-26
Status:Open Resolved:
Product:OS X Product Version:10.12
Classification: Reproducible:Always
 
Apps need an "Info.plist" key that they can use to opt out of Gatekeeper Path Randomization (GPR). GPR was introduced in the macOS 10.12 (16A201w)  seed, and it was designed to prevent an attack where a validly signed app loads malicious resources external to the app bundle, at a path relative to the app bundle. However, only a small percentage of apps load external resources relative to their app bundle path. The vast majority of apps are not even vulnerable to the attack that GPR was designed to prevent. Nonetheless, GPR is applied to them, which causes various forms of breakage. For example, GPR breaks built-in software update systems such as the very popular Sparkle. If an app does not load external, bundle path relative resources, and thus is not vulnerable to the attack, then the app should be able to specify this in its Info.plist and receive an except to GPR. There are so many ways that GPR breaks our apps and the apps of other third-party developers that I would have to spend hours just spelling them out here, and we would have to spend innumerable, very expensive engineering hours trying to work around the breakage somehow. An Info.plist key would go a long way toward mitigating the breakage.

It should be noted that signed disk images are not a good alternative to the Info.plist key. First, we deliberately chose to distribute our apps via zip files rather than disk images, because many customers find disk images inconvenient and confusing. Customers often attempt to run apps directly from the disk image, which is undesirable, and then when they logout or reboot, and the disk image gets automatically ejected, the customer is perplexed because the app is gone. It's also an extra step to copy the app from the disk image to their boot volume. We would have to change our build system to produce signed disk images instead of zips, which is problematic for several reasons. Signed disk images require Mac OS X 10.11, but we sometimes need to build from 10.10. Moreover, any build process involving code signing is usually difficult and runs into problems. Perhaps the biggest problem is, our software update system is not designed to handle signed disk images, so even if we start shipping new versions of the apps with signed disk images, it's going to be problematic to ship those updates via our software update system to older versions of the apps.

Comments

Apple says this has been closed. Any news on the resolution?

Duplicated.

By pixinsight.support at Sept. 21, 2016, 7:04 a.m. (reply...)

FileMaker runtime apps don´t work at all

FileMaker 13, 14 and 15 based runtime apps don´t work with GPR at all, since they can´t find their database file - "primary file not found" is the only thing you get. And it happens with signed versions too and signing the dmg doesn´t help either.

I duped the radar as well. Apple marked my radar as a dupe (still leaving my report open), so they are likely reading these reports!

By zorgiepoo at July 2, 2016, 3:01 p.m. (reply...)

Dupe'd


Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!