Gatekeeper Path Randomization

Jeff Johnson:

Under what circumstances does App Translocation occur? First, the app must have a com.apple.quarantine extended attribute. If you delete the quarantine xattr, then App Translocation does not occur, and the app will launch from where it was unarchived, like normal. Second, the app must be opened by Launch Services. This usually means Finder, but it can also mean open from Terminal, for example. If you launch the app executable directly from bash, on the other hand, App Translocation does not occur. Third, the app must not have been moved — by Finder. If you move the app, using Finder, from the app’s original unarchived location to another folder, even a subfolder, e.g., ~/Downloads/Test/, then App Translocation does not occur. However, if you move the app using mv from Terminal, then App Translocation will still occur. Normally you would move the app from ~/Downloads to /Applications, and that would cause the app to be launched from /Applications like normal, but the locations of the particular folders don’t seem to matter. The mere act of moving the app using Finder stops App Translocation from happening. Indeed, once you’ve moved the app once, it will no longer experience App Translocation again, even if you then move it back to ~/Downloads.

[…]

How does App Translocation affect us, as app developers? For the most part, the apps seem to work as before. After all, it shouldn’t matter whether your app is launched from /Applications, from ~/Downloads, or from the Xcode build folder. However, when the app runs from a read-only volume, it cannot update itself to a newer version. App Translocation prevents software update mechanisms such as Sparkle from working.

Jeff Johnson:

This is because the vulnerability that Apple is attempting to fix is what the presenter called a “repackaging” problem. The repackaging problem was illustrated at the end of Patrick Wardle’s paper, where he gives an example of a maliciously crafted disk image. It was clear from the session that Apple is concerned not just with Wardle’s dylib hijacking but also with any resources loaded external to the app bundle. Some apps will load external scripts or html, either of which could be employed in an attack. A locally loaded html page has access to the user’s file system, so it could wreak havoc if the page contains maliciously crafted JavaScript. App Translocation was designed to prevent malicious external resources from being loaded by changing the relative paths from the app bundle.

See also: WWDC Session 706: What’s New in Security.

Update (2016-06-17): Jeff Johnson:

The fundamental problem, the primary cause of both of the flaws I discovered, is that App Translocation happens automatically, without any awareness by or notification to the user, but App Translocation is turned off by a manual action by the user — moving the app bundle in Finder — again without any awareness or notification.

[…]

The more I learn about App Translocation, the more I feel that it is a bad idea with a botched implementation.

Update (2016-06-29): Jeff Johnson (tweet, Hacker News):

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.

[…]

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.

Update (2016-06-30): Jeff Johnson:

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.

Update (2016-07-11): The public beta version of DropDMG can now create signed disk images to avoid Gatekeeper path randomization.

Update (2016-07-21): DropDMG 3.4 is now available with support for creating signed .dmg disk images and .xip archives.

Update (2016-07-26): Jeff Johnson:

As I mentioned in an earlier blog post, there’s a new API for App Translocation in the 10.12 SDK: <Security/SecTranslocate.h>. However, if you’re sane, you’re not shipping your apps yet with the 10.12 SDK. So how can you detect App Translocation in your shipping apps? The trick is that since you can’t link against the new functions, you have to load them at runtime. I’ve provided sample code below.

Update (2016-08-18): Jeff Johnson:

Therefore, we’re faced with the odd situation where App Translocation affects our apps, but there’s no supported way to detect it, not even with the latest SDK. It’s unclear how this situation can be tenable. As we’ve seen, though, Apple works in mysterious ways. Thankfully, the SecTranslocate symbols still exist in the Security.framework binary, so the technique explained in my last blog post continues to work. The Dude abides.

Update (2016-10-07): Jeff Johnson:

In an earlier post I mentioned that the I stumbled upon a different place where a kind of API for App Translocation still exists in macOS 10.12 Sierra: the security command-line tool. It’s not in the man page, so don’t bother to RTFM, but you will find it at the end of the usage information, when you simply type security into Terminal[…]

Update (2017-02-18): Johannes Tiefenbrunner:

If you put these two things together it becomes impossible to create permanent (“Forever”) rules in Little Snitch for apps that are still in quarantine, because each time they are launched they will be launched from a different path.

Update (2018-06-21): Jeff Johnson:

The kicker is that this App Translocation issue only occurred on Sierra. On High Sierra, the SafariServices API calls work even when the app is running from the Downloads folder and undergoing App Translocation. So it appears that SafariServices on Sierra was failing to account for App Translocation, and that bug was fixed in High Sierra.

Code Signing Disk Image DropDMG Extended Attributes Gatekeeper Mac macOS 10.12 Sierra Malware Security

6 Comments RSS · Twitter

---

---

---

---

---

---

Leave a Comment

Name

E-mail (will not be published)

Web site

Δ