'XARA' is an acronym for 'unauthorized cross-app resource access' and lumps together several exploits against OS X and iOS.

Update: Apple has provided iMore with the following comment on the XARA exploits:

Earlier this week we implemented a server-side app security update that secures app data and blocks apps with sandbox configuration issues from the Mac App Store," an Apple spokesperson told iMore. "We have additional fixes in progress and are working with the researchers to investigate the claims in their paper."

The XARA exploits, recently disclosed to the public in a paper titled Unauthorized cross-app resource access on Mac OS X and iOS, target the OS X Keychain and Bundle IDs, HTML 5 WebSockets, and iOS URL schemes. While they absolutely need to be fixed, like most security exploits, they have also been needlessly conflated and overly sensationalized by some in the media. So, what's really going on?

What is XARA?

Simply put, XARA is the name being used to lump together a group of exploits that use a malicious app to gain access to the secure information transited by, or stored in, a legitimate app. They do this by placing themselves in the middle of a communications chain or sandbox.

What does XARA target exactly?

On OS X, XARA targets the Keychain database where credentials are stored and exchanged; WebSockets, a communication channel between apps and associated services; and Bundle IDs, which uniquely identify sandboxed apps, and can be used to target data containers.

On iOS, XARA targets URL schemes, which are used to move people and data between apps.

Wait, URL scheme hijacking? That sounds familiar...

Yes, URL scheme hijacking isn't new. It's why security-conscious developers will either avoid passing sensitive data via URL schemes, or at the very least take steps to mitigate the risks that arise when choosing to do so. Unfortunately, it appears that not all developers, including some of the biggest, are doing that.

So, technically, URL hijacking is not an OS vulnerability so much as a poor development practice. It's used because no official, secure mechanism is in place to accomplish the desired functionality.

What about WebSockets and iOS?

WebSockets is technically an HTML5 issue and affects OS X, iOS, and other platforms including Windows. While the paper gives an example of how WebSockets can be attacked on OS X, it doesn't give any such example for iOS.

So XARA exploits primarily affect OS X, not iOS?

Since "XARA" lumps together several different exploits under one label, and the iOS exposure seems much more limited, then yes, that appears to be the case.

How are the exploits being distributed?

In the examples given by the researchers, malicious apps were created and released to the Mac App Store and iOS App Store. (The apps, especially on OS X, could obviously be distributed via the web as well.)

So were the App Stores or app review tricked into letting these malicious apps in?

The iOS App Store was not. Any app can register a URL scheme. There's nothing unusual about that, and hence nothing to be "caught" by the App Store review.

For the App Stores in general, much of the review process relies on identifying known bad behavior. If any part of, or all of, the XARA exploits can be reliably detected through static analysis or manual inspection, it's likely those checks will be added to the review processes to prevent the same exploits from getting through in the future

So what do these malicious apps do if they're downloaded?

Broadly speaking, they intermediate themselves into the communications chain or sandbox of (ideally popular) apps, and then wait and hope you either start using the app (if you don't already), or start passing data back and forth in a way they can intercept.

For OS X Keychains, it includes pre-registering or deleting and re-registering items. For WebSockets, it includes preemptively claiming a port. For Bundle IDs, it includes getting malicious sub-targets added to the access control lists (ACL) of legitimate apps.

For iOS, it includes hijacking the URL scheme of a legitimate app.

What sort of data is at risk from XARA?

The examples show Keychain, WebSockets, and URL scheme data being snooped as it's transited, and Sandbox containers being mined for data.

What could be done to prevent XARA?

While not pretending to understand the intricacies involved in implementing it, a way for apps to securely authenticate any and all communications would seem to be ideal.

Deleting Keychain items sounds like it has to be a bug, but pre-registering one seems like something authentication could protect against. It's non-trivial, since new versions of an app will want to, and should be able to, access the Keychain items of older versions, but solving non-trivial problems is what Apple does.

Since Keychain is an established system, however, any changes made would almost certainly require updates from developers as well as Apple.

Sandboxing just sounds like it needs to be better secured against ACL list additions.

Arguably, absent a secure, authenticated communications system, developers shouldn't be sending data through WebSockets or URL Schemes at all. That would, however, greatly impact the functionality they provide. So, we get the traditional battle between security and convenience.

Is there any way to know if any of my data is being intercepted?

The researchers propose that malicious apps wouldn't just take the data, but would record it and then pass it on to the legitimate recipient, so the victim wouldn't notice.

On iOS, if URL schemes are really being intercepted, the intercepting app would launch rather than the real app. Unless it convincingly duplicates the expected interface and behavior of the app it's intercepting, the user might notice.

Why was XARA disclosed to the public, and why hasn't Apple fixed it already?

The researchers say they reported XARA to Apple 6 months ago, and Apple asked for that much time to fix it. Since that time had elapsed, the researchers went public.

Strangely, the researchers also claim to have seen attempts by Apple to fix the exploits, but that those attempts were still subject to attack. That makes it sound, at least on the surface, that Apple was working on fixing what was initially disclosed, ways to circumvent those fixes were found, but the clock wasn't reset. If that's an accurate read, saying 6 months has passed is a little disingenuous.

Apple, for its part, has fixed numerous other exploits over the last few months, many of which were arguably greater threats than XARA, so there's absolutely no case to be made that Apple is uncaring or inactive when it comes to security.

What priorities they have, how difficult this is to fix, what the ramifications are, how much changes, what additional exploits and vectors are discovered along the way, and how long it takes to test are all factors that need to be carefully considered.

At the same time, the researchers know the vulnerabilities and may have strong feelings about the potential that others have found them and may use them for malicious purposes. So, they have to weigh the potential damage of keeping the information private versus making it public.

So what should we do?

There are many ways to get sensitive information from any computer system, including phishing, spoofing, and social engineering attacks, but XARA is a serious group of exploits and they need to be fixed (or systems need to be put in place to secure against them).

No one needs to panic, but anyone using a Mac, iPhone, or iPad should be informed. Until Apple hardens OS X and iOS against the range of XARA exploits, the best practices for avoiding attack are the same as they've always been — don't download software from developers you don't know and trust.

Where can I get more information?

Our security editor, Nick Arnott, has provided a deeper dive into the XARA exploits. It's a must-read:

Nick Arnott contributed to this article. Updated June 19 with comment from Apple.