It’s the easiest thing in the world to write a headline that tells you to panic; it’s much harder to write one that says something is very wrong, but the odds of it occurring are very low and getting lower. Last week’s release of a research paper that showed exploits that were possible in App Store-approved software in iOS and OS via intra-application shared resources was significant. However, most of the media covering it (including us) got the nuance right.
The App Store wasn’t compromised, nor is there a way for Internet-distributed malware to make good use of these flaws. Rather, through lengthy work that included consultation with software makers and Apple, it seems that the exploits were grossly mitigated before the paper was released. Finer steps to root out the spots that can be vectors for attack will clearly come.
It’s also nice to hear Apple respond quickly and forcefully to a potentially significant security hole. The paper was released on Wednesday, and Apple confirmed that it had made server-side changes and was working with researchers on additional issues.
What should you be concerned with as an app buyer?
Which flaws and which apps
To recap: researchers found four categories of severe flaws, three of which affect only apps in the Mac App Store, and a fourth can be used by malware in the Mac or iOS App Store. An attacker has to develop and get an app approved by Apple, then convince people to obtain it for any of the exploits to be used.
While iOS users have zero choice about where they get apps, Mac users can pick from the App Store or any source. Based on best-selling lists and the abdication from or disinterest in the Mac App Store by some leading developers, most apps downloaded are from Apple or a handful of well-known companies. For a malicious developer to even get to users will require a lot of stars to be in alignment. The high bar makes it unlikely for criminals to try; governments might if they had particular targets in mind and could mask their intent.
The four flaws relate to snooping on keychain password entries, reading app-specific data storage that should be restricted to the app via user-approved conduits (like Evernote), intercepting browser-to-app communication, and—for both iOS and OS X—URL schemas that could contain access tokens being hijacked.
Because all the exploits require submission and approval of an app, Apple should have been able to change its screening process as long ago as October, after the researchers tested submitting apps with malicious inter-application components and having them approved. (The paper’s authors removed these apps immediately after approval.)
Apple can also rescreen all apps in the App Store for specifics sorts of uses mentioned in the paper and build it into future approvals. The keychain flaw, in which malware can essentially add itself as a legitimate party to read entries for other apps, should be something Apple can check apps for directly, but also obviously requires some system reengineering.
The statement from the company on Friday said that it has already made one fix: Apple “implemented a server-side app security update that secures app data and blocks apps with sandbox configuration issues from the Mac App Store.” That’s related to the second flaw I noted above, labeled “container cracking,” in which an app’s private data can be stolen by a subsystem that registers itself as if it were an already accepted extension.
The URL schema issue is straightforward, in that apps have to include these in a form that can be handed off to the OS. Apple can parse and test for this on both platforms. While apps can’t control where a schema redirects—a Facebook authorization request in Pinterest doesn’t know whether Facebook or malware has registered the Facebook app’s schema—but it can determine where a redirect came from. Developers can put in tests around this to prevent hanky-panky, although Apple may make changes in both OSes that obviate this need.
Researchers found some apps are already resistent to one or more exploits because of particular choices, and these could be turned into best practices or even requirements.
Others respond with advice and tools
AgileBits, makers of 1Password, were called out in the paper specifically, not because they made mistakes, but rather due to their browser plug-in integration, which is extremely useful. Researchers found they could hijack an Internet socket allowed under App Store guidelines and read passwords and other data when a user invoked 1Password to fill in values on a given website.
1Password developer AgileBits blogged about what users can do to protect themselves from the (unlikely) event that this bug would be exploited.
In a detailed blog post, AgileBits explained the limited circumstances in which this flaw could be exploited, and provided a few concrete ways to avoid it. Specifically, the company says to check “Always Keep 1Password Mini Running” in Preferences > General in its OS X app.
And on Monday, Facebook’s security team released an update to a developer tool called osquery that’s designed for monitoring OS X and Linux to add a way to check for modifications that relate to three of the exploits; socket-based communication isn’t included. The tool is free and part of Facebook’s community giveback, in that it profits not a bit (except in positive attention) from making it available. In a blog post, one of the security team’s engineers explains how an organization could make use of osquery to monitor continuously for telltale changes and alert an administrator.
There’s been a remarkably positive response to this research paper in part because the researchers provided months of upfront disclosure to Apple, AgileBits, and other firms, allowing changes to be put in place and the scope of the problem to be fully understood. Apple said on Friday, “We have additional fixes in progress and are working with the researchers to investigate the claims in their paper.”
This interplay of researcher, developer, community, and affected parties is a close to perfect case, especially when a zero-day exploit—one that can be potentially instantly invoked—comes about. I hope this sets a pattern for future security issues.
Author: Glenn Fleishman, Senior Contributor
Glenn Fleishman’s most recent books include Take Control of iOS and iPadOS Privacy and Security, Take Control of Calendar and Reminders, and Take Control of Securing Your Mac. In his spare time, he writes about printing and type history. He’s a senior contributor to Macworld, where he writes Mac 911.