Page 1 of 13

Unauthorized Cross-App Resource Access on MAC OS X and iOS

Luyi Xing

Indiana University

Bloomington

luyixing@indiana.edu

Xiaolong Bai

Indiana University

Bloomington, Tsinghua

University

bxl12@mails.tsinghua.edu.cn

Tongxin Li

Peking University

litongxin@pku.edu.cn

XiaoFeng Wang

Indiana University

Bloomington

xw7@indiana.edu

Kai Chen

Indiana University

Bloomington, Chinese

Academy of Sciences

chenkai010@gmail.com

Xiaojing Liao

Georgia Institute of

Technology

xliao@gatech.edu

Abstract

On modern operating systems, applications under the same

user are separated from each other, for the purpose of pro- tecting them against malware and compromised programs.

Given the complexity of today’s OSes, less clear is whether

such isolation is effective against different kind of cross-app

resource access attacks (called XARA in our research). To

better understand the problem, on the less-studied Apple

platforms, we conducted a systematic security analysis on

MAC OS X and iOS. Our research leads to the discovery of

a series of high-impact security weaknesses, which enable a

sandboxed malicious app, approved by the Apple Stores, to

gain unauthorized access to other apps’ sensitive data. More

specifically, we found that the inter-app interaction services,

including the keychain and WebSocket on OS X and URL

Scheme on OS X and iOS, can all be exploited by the mal- ware to steal such confidential information as the passwords

for iCloud, email and bank, and the secret token of Ever- note. Further, the design of the App sandbox on OS X was

found to be vulnerable, exposing an app’s private directory

to the sandboxed malware that hijacks its Apple Bundle ID.

As a result, sensitive user data, like the notes and user con- tacts under Evernote and photos under WeChat, have all

been disclosed. Fundamentally, these problems are caused

by the lack of app-to-app and app-to-OS authentications.

To better understand their impacts, we developed a scanner

that automatically analyzes the binaries of OS X and iOS

apps to determine whether proper protection is missing in

their code. Running it on hundreds of binaries, we confirmed

the pervasiveness of the weaknesses among high-impact Ap- ple apps. Since the issues may not be easily fixed, we built

a simple program that detects exploit attempts on OS X,

helping protect vulnerable apps before the problems can be

fully addressed. We further discuss the insights from this

study and the lessons learnt for building a securer system.

Permission to make digital or hard copies of all or part of this work for

personal or classroom use is granted without fee provided that copies are

not made or distributed for profit or commercial advantage and that copies

bear this notice and the full citation on the first page. To copy otherwise, to

republish, to post on servers or to redistribute to lists, requires prior specific

permission and/or a fee.

Copyright 20XX ACM X-XXXXX-XX-X/XX/XX ...$15.00.

1. INTRODUCTION

The pervasiveness of computing technologies and emerg- ing security threats they are facing have profoundly changed

the security designs of modern operating systems (OS). Mov- ing away from the traditional threat model in which all appli- cations (app for short) under the same user trust each other

with their information assets, today’s OSes tend to separate

those apps and their resources, in an attempt to prevent

a malicious or compromised program from causing damage

to others. This has been achieved through a variety of app

isolation mechanisms: each app is confined in its partition

with a minimum set of privileges, called sandbox, and needs

to explicitly require additional capabilities (e.g., access to

camera, audio, etc.) from the OS or the user. Such a secu- rity model has been adopted by most mainstream systems,

including Windows, MAC OS X, Android, iOS, etc. With

its popularity, the effectiveness of the technique, however,

has still not been fully understood, due to the complexity of

a modern OS, which makes comprehensive protection chal- lenging.

Unauthorized cross-app resource access. Recent stud- ies show that sandboxed Android apps can still get access to

other apps’ resources and acquire system capabilities with- out proper authorization [26]. For example, the developer

could accidentally make public an app’s interface for inter- process communication (IPC), through which its internal

service or activity can be triggered by a message (called In- tent) from an unauthorized app to acquire sensitive data [23]

or elevated privileges (e.g., access to audio, GPS, etc.) [16,

22, 18]. Fundamentally, the problem is caused by the mi- gration of the threat model and the transitional pain that it

comes with: both the OS designer and the app developer are

less used to the mindset that all apps, even when they all be- long to the same user, should treat each other as untrusted,

and proper security checks should always be performed in

all aspects of app-to-app and app-to-system interactions.

In those attacks, malicious code under some isolation con- straints manages to gain access to other apps’ resources or

affect the way they are used by legitimate apps, when it

is not authorized to do so. We call such a security threat

unauthorized cross-app resource access or XARA. Although

specific instances of XARA are found on the Android plat- form, less known is whether it is indeed a generic issue. Par- ticularly, we do not know whether app isolation works effec- 1

Page 2 of 13

tively on MAC OS X and iOS, which are widely considered

to be securer than Android. These operating systems offer

unique mechanisms to confine apps and support cross-app

interactions, very different from those provided by Android.

Specifically, the construction of Apple sandboxes is signif- icantly different from that of Android, in which each app

is given a unique User ID (UID), allowing the Linux user

protection to separate the apps. In contrast, an Apple app

is identified by its Apple ID, which contains a Bundle ID

(BID) token used by the OS to enforce sandbox policies.

The uniqueness of the token is ensured by the Apple Store.

Also, OS X supports complicated cross-app resource sharing.

For example, its keychain service allows multiple apps to

share credentials among them through an access-control list

(Section 3.1), which is not supported on other systems like

Android. In addition to cross-app resource sharing, other

cross-app interactions, i.e., IPC on Apple platforms, also

differ from those on Android. Examples includethe URL

Scheme uniquely associated with one single app, for launch- ing it with an URL1

. So far, little has been done to under- stand whether the construction of app isolation on Apple

platforms is secure and whether its cross-app mechanisms

can bring in XARA risks never known before.

Our work. We conducted the first study on the XARA risks

of Apple’s isolation mechanisms, and discovered surprising

security-critical vulnerabilities: major cross-app resource- sharing mechanisms (such as keychain) and communication

channels (including WebSocket and Scheme) turn out to be

insufficiently protected by both the OS and the apps using

them, allowing a malicious program to steal from these apps

sensitive user data; also the BID-based sandbox construction

is found to be less reliable than expected, and its resource- sharing mechanism can be exploited by the malicious app

to break the sandbox confinement on OS X, gaining full

access to other apps’ directories (called container ). Note

that not only does our attack code circumvent the OS-level

protection but it can also get through the restrictive app

vetting process of the Apple Stores, completely defeating its

multi-layer defense.

Looking into the root cause of those security flaws, we

found that in the most cases, neither the OS nor the vulner- able app properly authenticates the party it interacts with.

To understand the scope and magnitude of this new XARA

threat, we developed an analyzer for automatically inspect- ing Apple apps’ binaries to determine their susceptibility to

the XARA threat, that is, whether they perform security

checks when using vulnerable resource-sharing mechanisms

and IPC channels, a necessary step that has never been made

clear by Apple. In our study, we ran the analyzer on 1,612

most popular MAC apps and 200 iOS apps, and found that

more than 88.6% of the apps using those mechanisms and

channels are completely exposed to the XARA attacks (Sec- tion 4.2), and every app’s container directory has been fully

disclosed. The consequences are dire: for example, on the

latest Mac OS X 10.10.3, our sandboxed app successfully

retrieved from the system’s keychain the passwords and se- cret tokens of iCloud, email and all kinds of social networks

stored there by the system app Internet Accounts, and bank

and Gmail passwords from Google Chrome; from various

1On Android, an Intent-based Scheme is different as it can be

connected to multiple apps, which the user can choose once the

scheme is triggered.

IPC channels, we intercepted user passwords maintained by

the popular 1Password app (ranked 3rd by the MAC App

Store) and the secret token of Evernote (ranked 3rd in the

free “Productivity” apps); also, through exploiting the BID

vulnerability, our app collected all the private notes under

Evernote and all the photos under WeChat. We reported

our findings to Apple and other software vendors, who all

acknowledged their importance. . We also built an app that

captures the attempts to exploit the weaknesses.

Our study also shows that this XARA hazard is indeed

general, across different platforms. Even though iOS drops

many useful functionalities of OS X (e.g., keychain’s ac- cess control list for sharing passwords or tokens across apps)

and therefore less vulnerable, it is still not immune to the

threat. Particularly, its major IPC channel, Scheme, is

equally subject to the hijacking attack we discovered on

MAC OS X (Section 3.4). Further, the WebSocket problem

(Section 3.3) actually comes from HTML5, which happens

when a browser extension is connecting to a local program.

We found that the same attack can also succeed on iOS and

Windows. Interestingly, compared with OS X and iOS, An- droid looks pretty decent in terms of its protection against

the XARA threat: at the very least, it offers a mechanism to

protect its Intent-based IPC, through assigning a private

attribute to the service and activity or guarding them with

permissions, which are missing on the Apple platforms. We

further discuss the lessons learnt from our study, particu- larly the need for clarifying the responsibilities for protect- ing a cross-app mechanism between the OS provider and

the app developer, and present key principles for avoiding

XARA pitfalls when building new systems (Section 5).

Contributions. The contributions of the paper are out- lined as follows:

• New understanding of the XARA threat. We are the first

to identify the generality of the XARA problem and system- atically investigate the threat on the Apple platforms. Our

study brings to light a series of unexpected, security-critical

flaws that can be exploited to circumvent Apple’s isolation

protection and its App Store’s security vetting. The con- sequences of such attacks are devastating, leading to com- plete disclosure of the most sensitive user information (e.g.,

passwords) to a malicious app even when it is sandboxed.

Such findings, which we believe are just a tip of the ice- berg, will certainly inspire the follow-up research on other

XARA hazards across platforms. Most importantly, the new

understanding about the fundamental cause of the problem

(Section 5) is invaluable to the development of better app- isolation protection for future OSes.

• New effort to mitigate the threat. We developed new tech- niques for identifying the apps vulnerable to the XARA

threat, and the attempts to exploit them during an oper- ating system’s runtime.

Roadmap. The rest of the paper is organized as follows:

Section 2 provides the background information for our re- search and the assumptions we made; Section 3 elaborates

the security analysis we performed on OS X and iOS, and

the security problems we discovered; Section 4 describes the

design and implementation of the automatic analyzer, the

findings made by running the tool on popular apps and the

app-level mitigation we developed; Section 5 highlights the

lessons learnt from our study; Section 6 reviews the related

prior research and Section 7 concludes the paper.

2

Page 3 of 13

2. BACKGROUND

In this section, we describe how app isolation techniques

work on popular systems like Android, MAC OS X and iOS,

the way they handle inter-app communication and security

risks that come with such a strategy. Also, we present the

adversary model underlying our study.

App sandboxing. App sandboxing plays a critical role

in the Android security architecture. Each Android app is

given a unique UID and runs as the user. Sensitive resources

are assigned to Linux groups such as GPS, Audio, etc. This

treatment automatically isolates one app from others under

the Linux user and process protection. To access system

resources, an app needs to request permissions from the OS

or the user. A permission can also be defined by the app

for sharing its resources with authorized parties (those with

the permission) through the interfaces like content providers,

Intent receiver, etc.

The Apple sandbox first appears on MAC OS X, which

utilizes the TrustedBSD mandatory access control frame- work to enforce its security policies at the system-call level.

Since OS X 10.7.5 Lion, all apps submitted to the MAC App

Store are required to be sandboxed, with some exceptions

given to those that need to run as native code. On the OS

side, a service called Gatekeeper blocks the apps not signed

by either the Apple Store or a trusted developer from being

installed2

. This ensures that with proper security configu- rations, most apps running on a MAC device are under the

sandbox confinement. In the meantime, OS X maintains

its compatibility with the traditional OS security design,

hosting trusted native programs that run with the user’s

privileges. On iOS, however, apps are much simpler (e.g.,

without intensive document operations) and can therefore

all be sandboxed.

Unlike Android, which isolates an app solely based upon

its UID, the Apple platforms just utilize UIDs to classify

apps into groups. For example, on OS X all the apps from

the MAC app store operate under the UID of the current

OS user, and those on iOS under the user mobile. On

these platforms, separation is actually enforced through the

TrustBSD’s API interpositions. Each app is identified by its

Apple ID, a two-part string that consists of a Team ID Apple

assigns to the app developer, and a Bundle ID supplied by

the developer: for example, A1B2C3D4E5.com.apple.mail

where the first part is the Team ID and the rest compo- nents form the BID. Any app submitted to the Apple Stores

goes through a verification process that among other things,

ensures the uniqueness of the app’s BID. On OS X, this

identity also serves as the name of the app’s container di- rectory. Every sandboxed app on the Apple platforms is

given a container when it is first launched. The directory is

used to hold the app’s internal data and cannot be accessed

by other sandboxed apps from different developers.

An app within the sandbox has only limited privileges.

By default, it can only read and write files within its con- tainer and some public directories. This policy is enforced

by checking the developer’s signature on the app against

an access-control list (ACL) associated with each directory

(see Section 3.2). Also, it is not allowed to access network

sockets, built-in camera, microphone, printer and other re- sources. Whenever use of such resources becomes necessary,

the app explicitly requires them by declaring a set of entitle- 2This setting can be turned off.

ments within its property file (called plist file, very much like

the Android manifest file). Each entitlement is a key-value

pair that identifies a specific capability (e.g., access to cam- era). They are reviewed by the Apple Stores to determine

whether the capabilities should be granted. For some capa- bilities, such as access to GPS locations, camera, etc., the

OS further asks for the user’s permission during the app’s

runtime.

IPC on the Apple platforms. Among the small set of

operations that a sandboxed app is allowed to do by de- fault is the capabilities to perform some types of interprocess

communication. OS X supports a variety of IPC channels,

including traditional UNIX ones (e.g., pipe, UNIX domain

socket, shared memory) and Apple-specific mechanisms like

distributed objects and URL schemes. One unique IPC

mechanism for both OS X and iOS is Scheme: an app can

invoke another specific app to work on a task with a URL

click if the latter registers with the OS the scheme part of the

URL. For example, the URL yelp://search?terms=Coffee,

once triggered, let one app launch the Yelp app to search for

“Coffee” nearby. Here, the “yelp://” part is a scheme. Al- though this mechanism is also used on Android, which has

been implemented using Intent, it is different from that for

OS X and iOS since Apple’s OSes only allow one single app

to be associated with a scheme on a device, while on An- droid, the user is asked to choose a scheme’s owner when

there are more than one. This major difference enables our

scheme hijacking attack (Section 3.4) which, however, does

not pose a threat on Android. To register a scheme, an

Apple app needs to register it with the OS. This is done on

OS X and iOS by simply declaring the scheme in the app’s

plist file. Such a channel can be used by any sandboxed app

without specifying any entitlement.

Adversary model. In our research, we studied what an

isolated app can still do to collect sensitive data and utilize

critical sources that belong to other apps, when it is not

entitled to do so. For this purpose, we assume that ma- licious apps are submitted to the Apple Stores, which puts

them to the test of Apple’s restrictive review process. In the

case that they get published, the apps are supposed to be in- stalled by the user who also runs security-critical apps on her

device (laptop or smartphone). This is realistic, since apps

downloaded from the Apple Stores are widely considered to

be trusted, and particularly, almost all of them are confined

within the sandboxes. For the malware installed in this way,

we assume that they are isolated and only granted a small,

inconspicuous set of capabilities: in addition to what are of- fered by the OSes by default, they may need the networking

permission (only for the attack in Section 3.3). Note that

these entitlements are among the most innocent ones.

3. XARA MENACES

In our research, we conducted a systematic study on the

XARA threat over the Apple platforms, MAC OS X in par- ticular. Our focus is on how inter-app interaction channels

and services are protected under the sandboxing model, and

how isolation has been enforced on untrusted apps. Follow- ing we elaborate our findings, including the security-critical

flaws we discovered in the OS X keychain, BID-based sepa- ration as well as various IPC channels, i.e., WebSocket and

Scheme on both MAC OS X and iOS. Note that all our

attack apps were uploaded to the Apple App Stores and

3