Multiple vulnerabilities found in Mac OS X
Published June 17th, 2015 at 3:30 PM EDT , modified June 23rd, 2015 at 4:23 PM EDT
A group of six researchers at several universities in the US and China published a paper last weekend revealing the details of several different vulnerabilities in Mac OS X. These vulnerabilities all provide ways for a malicious app to gain access to data from another app. Frighteningly, these vulnerabilities can be exploited from a Mac App Store app, and can even allow an attacker to gain access to keychain entries!
The worst of these vulnerabilities would give a malicious app the ability to harvest data from the keychain under controlled circumstances. A malicious app could delete a keychain item created by another app, then create a lookalike replacement to which it has access. Later, when the target app went looking for that keychain item, it could be tricked into depositing information – such as passwords – which the malicious app could then access.
Another vulnerability involves the data storage mechanism for sandboxed apps. Apps downloaded from the Mac App Store are supposed to be “sandboxed,” meaning that they are isolated from each other and from the system to some degree. All such apps have their own folder in a hidden location, in which they can store any data they want to. This folder is given a name corresponding to the app’s “bundle ID,” which is a string like “com.apple.mail” (in the case of Apple’s Mail app).
Bundle IDs are supposed to be unique, and this is enforced in the App Store. Unfortunately, this is not enforced for any “helper apps” that may come bundled inside a particular app. This means that a malicious app could include a helper app that uses some other app’s bundle ID. This would, unfortunately, give that helper app, and thus the app containing it, access to that other app’s private data repository.
A third issue involves inter-process communication (IPC) through WebSocket. In Mac OS X, one app can act as a WebSocket server, listening on a particular port. Another app can send data to that port, intended for the server app. An example of this is the 1Password app, which uses this kind of communication between the 1Password browser extension and the 1Password app.
Unfortunately, a malicious process could get to that port first, and be in a position to receive data intended for another app. In the case of 1Password, it would be possible for a malicious app to imitate 1Password and receive password data from the 1Password browser extension.
Finally, the last vulnerability found involves special app-specific URLs, such as the “itms://” links that open the iTunes Store. Certain of these URL schemes are reserved for Apple to use, and no third-party apps can use them. However, many others exist that can be used by any third-party app.
On Mac OS X, the first app to register a URL scheme is the one that gets to use it. This means that if a malicious app could beat a legit app to registering a URL scheme, it could intercept data intended for that app. In the example cited in the paper, a “wunderlist://” URL containing a secret token used for accessing a Wunderlist account could be intercepted by a malicious app, thus giving that app access to the Wunderlist account in question.
All four of these vulnerabilities are very serious. Worse, they all can be exploited by Mac App Store apps. The researchers behind the paper were able to get apps into the App Store that included all of these exploits. (Those apps were pulled from the App Store by the researchers as soon as they were approved.) Even worse, Apple has known about these issues for 6 months, yet there are still no fixes in place.
All this sounds very bad, but fortunately there is some good news. First, there’s no known malware in the wild that uses these vulnerabilities yet. Some could certainly appear very soon, but there’s still the issue of getting the malware installed. There’s no known way to do that without fooling the user, although the high rate of adware infections right now shows that that’s not always difficult to do.
Further, even if malware using these vulnerabilities did get installed, is that really any worse than what malware could already do? Probably not. Once installed, malware can easily monitor keystrokes, take screenshots, track your browsing history, upload your personal files to a malicious server, etc, and all without relying on vulnerabilities or even the entry of an admin password. Malware has been doing this sort of thing for years without needing these kinds of vulnerabilities. Even Mac App Store apps have been found guilty of doing some of these things.
Apple should definitely fix these vulnerabilities, and should do so soon. However, it seems like a mistake to me to ever assume that running an untrusted app is safe. If an untrusted app has gotten onto your system, you’ve got serious problems, regardless of whether there are vulnerabilities like these present or not. To protect yourself, just be cautious about the apps that you install on your computer. Only download them from the developer’s site and always research them thoroughly first. If you download from the Mac App Store, pay close attention to reviews and never download an app that is so new (or unpopular) that it has no reviews yet.
Tuesday, June 23, 2015 @ 4:20 pm EST: Apple has already fixed the issues with the App Store approval process, from the sounds of it. Further, I’ve heard from a developer who tried to duplicate the keychain vulnerability on his own system, and was unable to make it work. It seems the keychain vulnerability either may have been fixed already, without any announcement, or it is much harder to exploit than the paper describes.