The last couple of days, a paper with details about XARA vulnerabilities in OS X and iOS is getting a lot of attention [1]. If you haven't seen the term "XARA" before, then this is probably because cross-application-resource-access was normal in the past. Different applications has access to each other's data as long as the same user ran them. But more recently, operating systems like OS X and iOS made attempts to "sandbox" applications and isolate applications from each other even if the same user is running them.

These sand boxes were supposed to prevent a single malicious application from compromising the entire system. 

iOS uses sand-boxed applications exclusively as it limits application installs to the app store. In OS X, applications downloaded from the app store have to implement sand-boxing. But users are still able to download arbitrary applications that do not use sand-boxing. For example, one reason there are no effective anti-malware applications for iOS is that there is no way to load an application that would have privileges to inspect other applications.

However, applications still need to talk to each other, and developers use various methods offered by the operating system to send data to each other. This paper does outline how some of these methods can be used to access other applications beyond there intended scope.

To explain this with an example, I am going to use the "Keychain" access that has caused probably the most headlines. For others, and for more details, please refer to the original paper.

If an application would like to store a password in the iOS or OS X keychain, it needs to create a new entry. The application will check if an entry with it's name already exists. There are two options:

- The value does not yet exist (first time user sets up a password in this application)

In this case, the application will create a new entry. It has the option to secure it by only providing some applications access to the value. For example, if we would publish several applications, then we could allow all of our applications to access this entry. 

- The value already exists (the user already configured a password)

In this case, if the application has access to the entry, it can overwrite it or read it. If another application happened to use the same name, then the entry should be locked if that other application implemented the keychain entry correctly.

However, a malicious application, if run ahead of the victim application, can setup a password entry with the same name as the victim application IF the victim did not configure a password yet. The malicious application would then create an entry that is open to the victim application and of course remains open to the malicious application.

As mentioned before, Keychain is just one of the features suffering from problems with cross application resource access. For the most part, this has to be fixed by the operating system, and may require modifying APIs, which may not be backward compatible. Next, application developers may be able to add some mitigation, but it is not clear which methods will work for the different XARA abuse cases.

As a normal end user, the only thing you can do is be careful as to what applications you install. For iOS, Apple can add additional checklist items to its application review process, but the authors of the paper did manage to publish a proof of concept application.

For jail broken iOS devices, or for OS X users installing non-sand boxed applications, this vulnerability does not present any new risks. Mobile malware in particular is still rather uncommon.

[1] https://drive.google.com/file/d/0BxxXk1d3yyuZOFlsdkNMSGswSGs/view

(note that the paper is hosted on a shared Google drive and your Google user name may be visible to the authors)

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn