Zero Day?

June 15, 2016

Yesterday I wrote about App Translocation. Then yesterday evening I had a chance to watch the "What's New in Security?" WWDC session, and it filled in some details. What I call "App Translocation", Apple calls "Gatekeeper Path Randomization". I'm going to continue to call it "App Translocation", though, because that's shorter, and "Translocation" is a cool-sounding word. As usual, the Mac "news" media who reported on this got it wrong. They completely misunderstood the behavior. For all the news that's fit to print, just follow my blog.

The WWDC session presenter emphasized what my testing had confirmed: the way for the user to turn off App Translocation is to move the app bundle, and only the app bundle. In other words, you cannot turn off App Translocation simply by moving the folder containing the app bundle. 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. If an app has a valid, Gatekeeper-approved code signature, then it should be impossible to tamper with any resources inside its app bundle. However, if the app loads resources outside its app bundle, using a relative path from the bundle, then may be possible to package the app together with a maliciously crafted archive, so the user downloads the archive, launches the app, which is approved by Gatekeeper, but the app loads maliciously crafted external resources in the archive, and then it's game over. Or game on, depending on your perspective. Moving the entire archive to a different location in the file system would not help, because the app bundle would maintain the same relative path to the other resources in the archive. That's why App Translocation automatically copies the app bundle, to change the relative path from the app to the archive. That's why manually moving the app bundle in Finder turns off App Translocation, because once the relative path to the archive has changed, the app will no longer find the malicious external resources. Or will it...

If a zip archive contains multiple top-level items, it will unarchive to a folder. The zip might contain an app along with release notes or instructions, for instance. If you launch the app from within that folder, it will experience App Translocation, as expected. If you move the folder containing the app, then the app will continue to experience App Translocation, because the archive may contain maliciously crafted external resources, so the app still needs protection. If you move the app outside of the archive folder, App Translocation stops. It doesn't seem to matter where you move it. In particular, I noticed that if I download MyArchive.zip to ~/Downloads, it unzips to ~/Downloads/MyArchive/MyApp.app, and I move MyApp.app from ~/Downloads/MyArchive to ~/Downloads, App Translocation stops occurring. Are you feeling queasy yet?

Suppose that MyApp.app has a Gatekeeper-approved signature, and it loads the resource MyApp.app/../foo/bar. A simple-minded attacker would package MyApp.app together with a maliciously crafted foo/bar. If MyApp.app is located in ~/Downloads/MyArchive, then the path MyApp.app/../foo/bar leads to ~/Downloads/MyArchive/foo/bar, which means App Translocation would be needed to break the relative path and protect against loading the bad resource. If MyApp.app is moved to ~/Downloads, then the relative path MyApp.app/../foo/bar leads to ~/Downloads/foo/bar, which is empty, so we're safe now, right? Amirite?

What would a more clever attacker do, who was aware of App Translocation? The clever attacker might package the zip file so that it unarchives into ~/Downloads/foo. The foo folder would contain MyApp.app and foo/bar, like before, as well as bar at the top level. Cover all the bases. If the user then moves MyApp.app up one spot in the folder hierarchy, out of foo and directly into ~/Downloads, then the path ~/Downloads/foo/bar is no longer empty. It leads to a maliciously crafted resource. Oops!

Another thing to consider is that if an attacker is able to induce the user to download one maliciously crafted file, then why not two? Suppose that a validly signed app is normally distributed by its developer via dmg, with other resources at the top level of the dmg. So MyApp.app loads MyApp.app/../bar rather than MyApp.app/../foo/bar. Could the attacker not arrange so that the user ends up with both ~/Downloads/MyArchive/MyApp.app and ~/Downloads/bar? That by itself is not a problem, because of App Translocation, but it becomes a problem if the user moves MyApp.app up into ~/Downloads.

I've been speaking mainly in hypotheticals. I will not provide a proof of concept today, for reasons. I encourage you to test the behavior yourself though. I have tested, and the results are not good. For Apple. Also keep in mind that I am not a security professional, merely an amateur, and I figured all of this out in two days. If I had been an actual attacker, you would be dead.