AppGuard — Real-time policy en-forcement for third-party applications

Michael Backes, Sebastian Gerling,Christian Hammer, Matteo Maffei,and Philipp von Styp-Rekowsky

Technischer Bericht Nr. A/02/2012

AppGuard - Real-time policy enforcementfor third-party applications

Michael Backes1,2 Sebastian Gerling1 Christian Hammer1 Matteo Maffei1Philipp von Styp-Rekowsky1

1 Saarland University2 Max Planck Institute for Software Systems

Abstract

Android has become the most popular operatingsystem for mobile devices, which makes it a promi-nent target for malicious software. The securityconcept of Android is based on app isolation andaccess control for critical system resources. How-ever, users can only review and accept permissionrequests at install time, or else they cannot installan app at all. Android neither supports permis-sion revocation after the installation of an app, nordynamic permission assignment. Additionally, thecurrent permission system is too coarse for manytasks and cannot easily be refined. We presentan inline reference monitor system that overcomesthese deficiencies. It extends Android’s permissionsystem to impede overly curious behaviors; it sup-ports complex policies, and mitigates vulnerabili-ties of third-party apps and the OS. It is the firstsolution that provides a practical extension of thecurrent Android permission system as it can be de-ployed to all Android devices without modificationof the firmware or root access to the smartphone.Our experimental analysis shows that we can re-move permissions for overly curious apps as well asdefend against several recent real-world attacks onAndroid phones with very little space and runtimeoverhead. AppGuard is available from the GooglePlay market1.

1 Introduction

Smartphones and tablet computers have becomeour every day companions, providing assistanceand comfort both in business and in our privatelives. In 2008 the Open Handset Alliance, a groupof companies led by Google [1], joined the smart-

1https://play.google.com/store/apps/details?id=com.srt.appguard.mobile

phone market with the open source software stackAndroid. By now, it has become the most popularoperating system for these devices [27]. More than450,000 apps in the official market Google Play andmore than 850,000 activations of new devices perday demonstrate the success of Android [42].However, the rapidly increasing numbers of mo-

bile devices also creates a vast potential for misuseas the development of new security concepts didnot keep pace with the development of new andfancy features. Mobile devices store a plethora ofinformation about our personal lives, and their sen-sors, GPS, camera, or microphone – just to namea few – potentially track us at all times. Further,the always-online nature of mobile devices makesthem both interesting and exposed targets for at-tackers and overly curious or maliciously spyingapps and trojan horses that hide their true na-ture in an unsuspicious app. For instance, socialnetwork apps were recently criticized for silentlydownloading and storing the user’s entire contactsto the network’s servers [17, 43]. While this behav-ior became publicly known, users are most oftennot even aware of what an app actually does withtheir data. Additional complications arise becauseeven fixes for recent security vulnerabilities in theAndroid operating system often take months untilthey are integrated into the vendor-specific OS byall vendors (a process called late updates). Dur-ing the time between Google’s fix (and the corre-sponding, publicly available vulnerability descrip-tion) and the vendor’s update, an unpatched sys-tem becomes the obvious target for exploits.Android’s security concept is based on isolation

of third-party apps and access control [2]. Accessto personal information has to be explicitly grantedat install time: During the installation of an appthe user is provided with a list of permissions theapp requests. The user can either accept all ofthese permissions, or else the app will not be in-

2

stalled. Users can neither dynamically grant andrevoke permissions at runtime, nor add restrictionsaccording to their personal needs. Furthermore,users are often not aware of a permission’s impact.They usually do not have enough information tojudge whether a permission is indeed required tofulfill a certain task. Research has shown that thisis the case even for Android app developers [24, 28].In order to overcome the current limitations with

Android’s permission system, researchers have pro-posed several approaches. Some work [40, 39, 38,12] focuses on extending the current permissionsystem, e.g. to prevent critical permission com-binations [20] (e.g. camera and Internet accesscould be used to implement a bug), but mostwork [9, 19, 28, 18, 29, 41] targets the detectionof privacy leaks and malicious third-party apps.While most of these approaches solve one particularproblem in theory, the vast majority of these sys-tems rely on modifications of the underlying soft-ware stack, which prevents deployment to off-the-shelf Android phones. So far, no solution simulta-neously removes permissions for overly curious be-havior, supports fine-grained security policies, pre-vents malicious applications from exploiting secu-rity vulnerabilities, and is easily deployed on allexisting Android devices.

1.1 Contributions

In this paper we present a novel policy-based se-curity framework for Android that overcomes theaforementioned limitations of Android’s securitysystem. Our approach proposes solutions for a va-riety of situations, in particular for:1. Revoking Android permissions dynamically.

Permissions can be granted and revoked at anytime after installation of an app. We supportgraceful revocation by selectively suppressingundesired operations without terminating theprogram.

2. Enforcing complex stateful and fine-grained se-curity policies. Policies can transform the se-quence of program actions in case the programdeviates from the security policy. We supportall predicates over that sequence as securitypolicy, which enables enforcement of any secu-rity property [37].

3. Policy-based quick-fixes for vulnerabilities inthird-party applications. When an app uses theAPI in an insecure way, we can transform theexecution to leverage alternative, secure func-

tionality. While it would be cleaner to fix theapp directly, a rapid work-around provides atemporary solution until the vendor providesan update.

4. Policy-based mitigation for vulnerabilities inthe operating system itself [10]. Known OSvulnerabilities pose a major threat to systemsecurity. Our framework defends against ma-licious apps that try to exploit a vulnerability,which is paramount to relieve the late updateproblem, where vendors integrate the fix at alater time than Google, or do not provide se-curity patches at all.

We have built a prototypical implementation calledAppGuard that supports all features listed. Oursystem does not require any modification to thecore software stack of the Android device and thussupports widespread deployment as a stand-aloneapp. AppGuard is based on inline reference mon-itoring [21]. It takes user-defined policies as inputand delivers a secured self-monitoring app. Ourevaluation on typical Android apps has shown verylittle overhead in terms of space and runtime. Thecase studies demonstrate the effectiveness of ourapproach: we successfully limit the excessive cu-riosity of apps, demonstrate complex policies andprevent several recent real-world attacks on An-droid phones. To the best of our knowledge, thisis the first defense against these attacks on phoneswith standard firmware.

2 The Android Monitor

Android’s current permission system fails to ad-dress some challenges of mobile applications: appsbasically dictate the permissions deemed necessaryand users have to grant them as requested short ofnot installing the application. Therefore, the in-dividual security requirements of users are ignoredas they are not really given a choice. In particu-lar, they are unable to grant each permission in-dividually and to grant and revoke certain permis-sions at a later time. This deficiency becomes par-ticularly severe as not only users have problemswith Android’s permission system. Song et al. [24]have shown that even application developers haveproblems requesting the “correct” permissions forthe functionality of their applications, since theAndroid documentation lacks completeness. If indoubt, they will therefore request too many per-missions in order to make their application work.Our AppGuard puts the user back in charge of

3

application permissions. With our system users aregiven the opportunity to decide both at installa-tion time of an app, as well as at any later point intime what an app is allowed to access. AppGuardprovides more fine-grained policies than Androiddoes itself, and, in contrast to other proposed solu-tions [38, 12], it is oblivious of the installed Androidfirmware. It can be installed on all existing Androidphones without modifying the core system, whichenables wide-spread deployment.Runtime policy enforcement for third-party ap-

plications is not an easy feat on unmodified An-droid systems. Android’s security concept strictlyisolates different applications installed on the samedevice, preventing them from interfering with eachother at runtime. Furthermore, applications can-not gain elevated privileges that would enable themto observe the behavior of other applications. Com-munication between apps is only possible via An-droid’s inter-process communication (IPC) mech-anism. So far, such communication requires bothparties to cooperate, rendering this channel unsuit-able for a generic runtime monitor.AppGuard tackles this open problem by fol-

lowing an approach pioneered by Erlingsson andSchneier [22] called inline reference monitor (IRM).The basic idea is to rewrite an untrusted applica-tion such that the code that monitors the applica-tion is directly embedded into its code. To this end,IRM systems incorporate a rewriter or inliner com-ponent, that injects additional security checks atcritical points into the application bytecode. Thisenables the monitor to observe a trace of security-relevant events, which typically correspond to invo-cations of trusted system library methods from theuntrusted application. To actually enforce a secu-rity policy, the monitor controls the execution ofthe application by suppressing or altering calls tosecurity-relevant methods, or even by terminatingthe program if necessary.In the IRM context, a policy is typically speci-

fied by means of a security automaton that defineswhich sequences of security-relevant events are ac-ceptable. Such policies have been shown to expressexactly the policies enforceable by runtime moni-toring [45]. Ligatti et al. differentiate security au-tomata by their ability to enforce policies by ma-nipulating the trace of the program [37]. Some IRMsystems [22, 15] implement simple truncation au-tomata, which can only terminate the program ifit deviates from the policy. However, this is oftenundesirable in practice. In their paper [37], Lig-

atti et al. formulate the notion of edit automata,which can transform the program trace by insert-ing or suppressing events. Monitors based on editautomata are able to react gracefully to policy vi-olations, e.g. by suppressing an undesired methodcall and returning a dummy value, but allowing theprogram to continue.AppGuard is an IRM system for Android with

the transformation capabilities of an edit automa-ton. Figure 1 provides a high-level overview of oursystem. We distinguish three main components:1. A set of security policies. AppGuard provides

various Android-specific security policies thatgovern access to platform API methods thatare protected by coarse-grained Android per-missions. These methods comprise e.g. meth-ods for reading personal data, creating net-work sockets, or accessing device hardware likethe GPS or the camera. As a starting point forthe security policies, we used the Android per-mission map by Song et al. [24].

2. The program rewriter. Android applica-tions run within a custom register-based JavaVM called Dalvik. Our rewriter manipulatesDalvik executable (dex) bytecode of untrustedAndroid applications and generates monitor-ing code according to the policies to harnessthe untrusted app.

3. A management component. It offers a graph-ical user interface that allows the user toset individual policy configurations on a per-application basis. In particular, policies canbe turned on or off and be parameterized. Inaddition, the management component keeps adetailed log of all security-relevant events, en-abling the user to monitor the behavior of anapplication.

3 Implementation

AppGuard is a stand-alone Android applicationwritten in pure Java and comprises about 6500 linesof code. It builds upon the dexlib library, which ispart of the smali disassembler for Android by BenGruver [32], for manipulating dex files. The size ofthe application package is roughly 750 Kb.

3.1 Policies

In our system, a policy is defined by a setof security-relevant method signatures and corre-sponding callback methods. In our system poli-

4

AppMonitor

App

Rewriter

Policies

logging

configManage-ment

Figure 1: Schematics of the AppGuard

cies are implemented as Java classes. The callbackmethods are mapped to a set of method signaturesusing a custom method annotation MapSignatures.Consider Fig. 2 as a basic example. This policyguards access to the openConnection() method inthe java .net.URL class and only allows connectionsto the host “wetter.com”.

A policy callback method gains access to thearguments of the original method call by declar-ing an equivalent list of parameters. In our ex-ample, the checkConnection(URL) callback methoduses the URL parameter to decide whether a con-nection should be allowed. If allowed, the callbackmethod will simply return such that the originalmethod call can proceed. If the connection is notallowed, an exception will be thrown that is eithercaught by the surrounding application code or bya synthetic handler introduced by the inliner. Inboth cases the original method call will be pre-vented by this scheme. Details will be discussedin the next subsection.

Furthermore, policies can be stateful and storesecurity state information in member variables ofthe policy class. The values of these variablesare preserved across callback method invocations.Member variables could also be used to store thecomplete history of intercepted methods.

In general, policy callbacks can perform arbi-trary operations. As an example, consider a policythat intercepts http connections and relays them toencrypted https, if available (cf. Fig. 3.) After call-ing the original method with the new arguments, itthrows an exception containing the returned value,which will be substituted for the return value of theoriginal method as described in the next section.

3.2 Inliner

The task of the inliner component is to divert thecontrol flow of the target application to the moni-toring code at invocation instructions to security-relevant methods. There are two strategies forpassing control to the monitor: Either at the call-site in the application code, right before the invo-cation of the security-relevant method, or at thecallee-site, i.e. at the beginning of the security-relevant method. The latter strategy is simplerand more efficient, because callee sites are easierto identify and less in number [5]. Unfortunately,callee-site rewriting is not applicable in our sce-nario, as security-relevant methods are declared inthe trusted Android platform libraries, which arepart of the non-modifiable firmware image. Thus,our inliner implements a call-site control flow di-version strategy. The inlining process consists ofthree steps:1. Merging the policy classes into the target ap-

plication’s classes .dex file, which contains allDalvik bytecode for the app.

2. Generating the MonitorInterface, which servesas a bridge between application code and poli-cies.

3. Injecting monitoring code around invocationsof security-relevant methods.

The policy classes are stored precompiled in a sep-arate dex file. In the first step, the inliner copies allclass declarations from this file to the classes .dexfile of the untrusted application.In order to connect invocations of security-

relevant methods to their policy callbacks, the in-liner generates a utility class calledMonitorInterfaceas the second step of the process. For eachsecurity-relevant method specified by the policies,the inliner generates a static guard method in theMonitorInterface class. The purpose of this guard

5

class InternetPolicy extends Policy {@MapSignatures({"Ljava/net/URL;->openConnection()"})public void checkConnection(URL url) throws Exception {

if (! "wetter.com".equals(url.getHost()))throw new IOException();

}}

Figure 2: Example policy protecting calls to java .net.URL.openConnection(). The callback methodcheckConnection(URL) allows connections to one host only.

class HttpsRedirectPolicy extends Policy {@MapSignatures({"Ljava/net/URL;->openConnection()"})public void checkConnection(URL url) throws Exception {

if (redirectToHttps(url)) {URL httpsUrl = new URL("https", url.getHost(), url.getFile());URLConnection returnValue = httpsUrl.openConnection();throw new MonitorException(returnValue);

}}}

Figure 3: Example policy that redirects http connections to https if available.

method is two-fold: First, callback methods of dif-ferent policies may be defined for a single security-relevant method. Thus, the guard method invokesall policy callbacks defined for this method signa-ture. Second, the guard method shares the signa-ture of the security-relevant method, including thereceiver object for virtual calls, which is passed asthe first method argument, if available. Thus, callsto the MonitorInterface require only minimal mod-ifications to the application code.In the final step, the inliner identifes all call sites

of security-relevant methods. If a matching in-struction is found, the inliner adds monitoring codearound the method call as depicted in Fig. 4 in theappendix. First, a method call to the correspond-ing guard method in theMonitorInterface is insertedright before the invocation of the security-relevantmethod. Second, the inliner adds a new try/catch-block around the inserted guard and the originalmethod call. This block enables policy callbacksto pass a return value to the application code ifthe original call is suppressed, which also allowsto protect security-relevant constructor methods.To this end, policy callbacks can throw a specialMonitorException that carries the return value tothe application code. In the inserted catch blockthis value is assigned to the intended variable (pos-sibly after type conversion).As pointed out earlier, another option for the

policy is to throw an exception that will be caughtby the original application code. Our example pol-icy in Fig. 2 makes use of this technique: If a con-nection is not allowed, the policy callback throws

an IOException, which resembles the behavior ofthe original URL->openConnection() method if aconnection error occurs.

3.3 Management

The management component of AppGuard allowsfor monitoring the behavior of inlined apps and forconfiguring policies at runtime. The policy config-uration is provided to the inlined app as a world-readable file. Its location is hardcoded into themonitor code during the inlining process. This ismotivated by the fact that invocations of security-relevant methods can occur before the inlined ap-plication is fully initialized and able to perform An-droid IPC.

The management component provides a log of allsecurity-relevant events, which enables the user tomake informed decisions about the current policyconfiguration. The log is maintained based on thesecurity-relevant method invocations encounteredin the self-monitoring application, which sends itsevents to the management application. For this di-rection of the communication we are leveraging astandard Android Service component. The asyn-chronous nature of Android IPC is not an issue,since security-relevant method invocations that oc-cur before the service connection is established arebuffered locally.

6

3.4 Challenges

In our implementation we faced two main difficul-ties: The handling of reflection and the handlingof virtual methods. In the following we will discussboth in detail.

3.4.1 Reflection

The Java Reflection API enables the inspection andmanipulation of classes, fields, methods, and con-structors at runtime without knowing their namesat compile time. It can also be used to instanti-ate new objects and to invoke methods. The lattertwo features are relevant to our IRM system as theyprovide alternative ways to invoke security-relevantmethods without their signatures appearing in theapplication bytecode.We deal with reflection by monitoring critical

methods of the Reflection API. To this end, weimplement a ReflectionPolicy that guards invo-cations of java .lang. reflect .Method->invoke(),Constructor->newInstance(), and java .lang.Class->newInstance(). Whenever one of thesemethods is invoked, the policy identifies the targetmethod of the reflective call by inspecting themethod parameters. If the target matches asecurity-relevant method, the policy reflectivelyinvokes the corresponding guard method in theMonitorInterface with the arguments of the reflec-tive call. This scheme ensures that the ReflectionAPI cannot be used to circumvent the inlinedmonitor.

3.4.2 Virtual methods

Virtual methods are a core concept of object-oriented programming. The target of a virtualmethod invocation is not determined statically, butdynamically based on the runtime type of the re-ceiving object. More specifically, an invoke-virtualinstruction with static target A->m can be resolvedto any method B->m at runtime, where B is a sub-class of A or A itself. Thus, virtual method invo-cations require special treatment by our inliner.We analyze the class hierarchy of application

code before the rewriting step and identify classesthat inherit security-relevant methods. If a classdoes not override the security-relevant method, weadd the signature of the inherited method to the setof security-relevant methods. The new signatureis associated with the same guard method as thesecurity-relevant method in the base class. If the

class does override a security-relevant method, wecan safely ignore invocations referencing the over-ridden method because any calls to the base classwithin the overridden method will be already pro-tected by the inliner.At the current state of the implementation, pol-

icy callbacks have to examine the runtime type ofthe receiver if they want to parameterize accordingto the target object. In our experiments, we havenot encountered any case where this was required.

3.5 Deployment

In comparison to existing approaches AppGuard’snovel security framework can be used on existingAndroid phones without requiring any changes tothe operating system. In particular, it does notrequire root access to the smartphone at any time.Third party applications installed on Android

are usually assigned distinct user ids. By default,application A can neither access nor modify appli-cation B.2 Therefore, our rewriter cannot simplymodify already installed applications. Instead, weleverage the fact that installation packages of thirdparty applications can be read from the file systemby any application. We read and unpack the ap-plication packages of the application to be secured,inline the security monitor, and finally repackageand reinstall the application. In order to start thisinstallation process, the user is asked in a prepara-tory step to uninstall the existing version of theapplication. Afterwards, it is possible to install therepackaged application without further problems.As mentioned, all Android applications need to

be signed with a developer key. Since our rewritingprocess breaks the original signature, we sign themodified app with a new key. However, apps signedwith the same key can access each other’s data ifthey declare so in their manifests. Thus, rewrittenapps are signed with keys based on their originalsignatures in order to preserve the intended behav-ior. In particular, two apps that were originallysigned with the same key, are signed with the samenew key after the rewriting process.Moreover, we ask the user to enable the OS-

option to allow installation of apps that have notbeen signed by the Google Android market. Dueto these two user interactions, no additional rootprivileges are required for AppGuard.

2Applications signed with the same developer key andthose that have the “shared user id”-flag set constitute spe-cial cases.

7

4 Experimental EvaluationIn this section, we present the results of our exper-imental evaluation. It focuses on the performanceof our framework and the evaluation of its effec-tiveness in different case studies. As testbed weused the Google Galaxy Nexus smartphone withAndroid 4.0.2. It has a dual-core 1.2 GHz ARMCPU from Texas Instruments (OMAP 4460) andfeatures 1GB RAM. For our off-the-phone evalu-ation we use a notebook with an Intel Core i5-2520M CPU (2.5 Ghz, two cores, hyper-threading)and 8GB RAM.

4.1 Performance Evaluation

AppGuard modifies apps installed on an Androiddevice by adding code at the bytecode level. Weanalyze the time it takes to inline an app and itsimpact on both size and execution time of the mod-ified app.Table 1 provides an overview of our performance

evaluation for the inlining process. We have testedAppGuard with 13 apps and inlined each of theapps with 9 policies (cf. section 4.2 for details onthe policies). In particular, we list the followingresults for each of the apps: size of the originalapplication package (Apk), size of the classes .dexfile before and after the inlining process (Dex andInl, respectively) and the resulting file size differ-ence (Diff), total number of instructions in theapplication code (Total), number of instructionsthat have been instrumented by the inliner (Chg),and, finally, the duration of the whole inlining pro-cess, both on the laptop and smartphone (PC andPhone, respectively).The size of the classes .dex file increases on av-

erage by approximately 45 Kb. The majority ofthis increase results from merging the monitoringframework and policy class definitions into the ap-plication code, while the inserted security checksonly have a minor influence on the file size. Theapplications in our benchmark exhibit significantdifferences in the total number of instructions aswell as in the size of the application package. Thesedifferences are reflected in the execution times ofthe inliner. In most cases, the total instructioncount has the largest impact on the runtime, asall instructions in the application code need to bescanned in order to identify invocations of security-relevant methods. For a few apps (e.g. AngryBirds), however, the runtime is dominated by re-building and compressing the application package

file (which is essentially a zip archive). The evalua-tion also clearly reveals the difference in computingpower between the laptop and the phone. Whilethe inlining process takes considerably more timeon the phone than on the laptop, we argue thatthis should not be a major concern as the inliner isonly run once per application.The runtime overhead introduced by the in-

line reference monitor is measured through micro-benchmarks (cf. Table 2.) We compare the exe-cution time of single function calls in three differ-ent settings: the original code with no inlining aswell as the inlined code with disabled and enabledpolicies (i.e. policy enforcement turned on or off) .Additionally, we present the overhead incurred forthe case where policies are disabled. We list theaverage execution time for each function call. Forthe case where we enforce policies we prevent theexecution of the respective function.For all function calls the instrumentation adds

a small runtime overhead due to additional code.However, when enabled policies prevent the partic-ular function call, the control flow change leads toa smaller overall execution time. Therefore, it isincomparable to the other execution times, so thatwe compute the overhead only for the disabled poli-cies. In either case, the incurred runtime overheadis negligible and does not adversely affect the ap-plication’s performance.

4.2 Case Study Evaluation

The conceptual design of AppGuard focuses onflexibility and introduces a variety of possibili-ties to enhance Android’s security features. Inthis section, we evaluate our framework in sev-eral case studies by applying different policies toreal world apps from Google’s application marketGoogle Play [30]. As a disclaimer, we would liketo point out that we use apps from the market forexemplary purposes only, without implications re-garding their security unless we state this explicitly.For our evaluation, we implemented 9 differ-

ent policies. Five of them are designed to revokecritical Android platform permissions, in partic-ular the Internet permission (InternetPolicy), ac-cess to camera and audio hardware (CameraPolicy,AudioPolicy), and permissions to read contacts andcalendar entries (ContactsPolicy, CalendarPolicy).Furthermore, we introduce a complex policy thattracks possible fees incurred by untrusted ap-plications (CostPolicy). The HttpsRedirectPolicy

8

Table 1: Inliner Evaluation: sizes of apk file, classes.dex, inlined classes.dex, diff. of dex file, # of totaland changed instructions, inlining time on PC and phone.

App (Version) Size [Kb] Instructions Time [sec]Apk Dex Inl Diff Total Chg PC Phone

Angry Birds (2.0.2) 15018 994 1038 +44 79311 100 6.5 43.4Barcode Scanner (4.0) 508 352 397 +45 46337 31 1.8 4.1Chess Free (1.55) 2240 517 561 +45 52615 71 3.2 7.9Dropbox (2.1.1) 3252 869 913 +44 90334 86 1.9 14.1Endomondo (7.0.2) 3263 1635 1680 +45 134452 88 2.6 23.0Facebook (1.8.3) 4013 2695 2744 +48 224285 218 3.2 47.3Instagram (1.0.3) 12901 3292 3337 +46 254032 137 4.2 66,4Post mobil (1.3.1) 858 1015 1056 +41 84407 58 1.7 11.6Shazam (3.9.0) 3904 2642 2690 +48 259644 221 2.8 47.5Tiny Flashlight (4.7) 1287 485 531 +46 46878 109 1.8 7.3Twitter (3.0.1) 2218 764 813 +48 105594 107 3.6 16.7Wetter.com (1.3.1) 4296 958 1000 +43 89655 36 2.2 15.7WhatsApp (2.7.3581) 5155 3182 3230 +48 437874 235 3.0 57.5

Table 2: Runtime comparison with micro-benchmarks for function calls in unmodified apps and inlinedapps with policies disabled and enabled. The runtime overhead is presented for the inlined app withdisabled policies.

Function Call Original Inlined App OverheadApp Pol. disabled Pol. enabled

Socket-><init>() 0.2879 ms 0.3022 ms 0.0248 ms 5.0%ContentResolver->query() 10.484 ms 11.138 ms 0.1 ms 6.2%Camera->open() 150.8 ms 152.36 ms 0.6 ms 1.0%

and MediaStorePolicy address security issues inthird-party apps and the OS. Finally, theReflectionPolicy described in section 3.4.1 monitorsinvocations of Java’s Reflection API. In the follow-ing case studies, we highlight 6 of these policies andevaluate them in detail on real-world apps.Our case studies focus on (a) the possibility to

revoke standard Android permissions - which is ar-guably the feature Android users desire most. Ad-ditionally, it is possible to (b) enforce fine-grainedpermissions that are not supported by Android’sexisting permission system, and, (c) to enforcecomplex and stateful policies based on the currentexecution trace. Finally, our framework providesquick-fixes and mitigation for vulnerabilities bothin (d) third-party apps and (e) the operating sys-tem.(a) Revoking Android permissionsMany Android applications request more permis-sions than necessary for achieving the intendedfunctionality. A prominent example is the Internetpermission android.permission.INTERNET, which

allows sending and receiving arbitrary data to andfrom the Internet. Although the majority of appli-cations requests this permission, it is not requiredfor the core functionality of an app in many cases.It is often used just for providing in-app advertise-ments. However, overly curious apps that, e.g., up-load the user’s entire contact list to their servers,and even trojan horses are recently reported on aregular basis. Unfortunately, users cannot simplyadd, revoke, or configure permissions dynamicallyat a fine-grained level. Instead, users have to de-cide at installation time whether they accept theinstallation of the app with the listed permissionsor they reject them with the consequence that theapp cannot be installed at all.AppGuard overcomes this unsatisfactory all-or-

nothing situation by giving users the chance tosafely revoke permissions at any time at a fine-grained level. We aim at a “safe” revocation ofpermissions, so that applications with revoked per-missions will not be terminated by a runtime ex-ception. To this end, we carefully provide proper

9

dummy return values instead of just blocking un-safe function calls [35]. We tested the revocation ofpermissions on several apps, of which we highlighttwo in the following.Case study: TwitterAs an example for the revocation of permissions, wechose the official app of the popular micro-bloggingservice Twitter. It recently attracted attention inthe media [43] for secretly uploading phone num-bers and email addresses stored in the user’s ad-dress book to the Twitter servers. While the app“officially” requests the permissions to access bothInternet and the user’s contact data, it did not indi-cate that this data would be copied off the phone.As a result of the public disclosure, the currentversion of the app now explicitly informs the userbefore uploading any personal information.We can stop the Twitter app from leaking any

private information by completely blocking accessto the user’s contact list. The contact data is usedas part of Twitter’s “Find friends” feature thatmakes friend suggestions to new users based on in-formation from their address book. Since friendscan also be added manually, AppGuard leveragesthe ContactsPolicy to protect the user’s privacy atthe cost of losing only minor convenience function-ality. Actual policy enforcement is done by moni-toring queries to the ContentResolver, which servesas a centralized access point to Android’s variousdatabases. Data is identified by a URI, which weexamine to selectively block queries to the contactlist by returning a mock result object. Our testswere carried out on an older version of the Twitterapp, which was released prior to their fix.Case study: Tiny FlashlightThe core functionality of the Tiny Flashlight appis to provide a flashlight, either using the camera’sLED flash, or by turning the whole screen white.At installation time, the app requests the permis-sions to access the Internet and the camera. Man-ual analysis indicates that the Internet permissionis only required to display online advertisements.However, in combination with the camera permis-sion this could in principle be abused for spyingpurposes, which would be hard to detect withoutfurther detailed code or traffic analysis. AppGuardcan block the Internet access of the app with theInternetPolicy (cf. section 3.1 and Fig. 2), which, inthis particular case, has the effect of an ad-blocker.We monitor constructor calls of the various Socketclasses, the java .net.url .openConnection() methodas well as several other network I/O functions, and

throw an IOException if access to the Internet isforbidden.Apart from the Internet permission, users might

not easily see why the camera permission is re-quired for this app. Here, our analysis indicatesthat – depending on the actual smartphone hard-ware – the flashlight can in some cases be ac-cessed directly, while in others only via the cam-era interface. Although requesting this permis-sion seems to be benign for this app, our ap-proach offers the possibility to revoke camera ac-cess. We enforce the CameraPolicy by monitoringthe android.hardware.Camera.open() method. Thepolicy simulates hardware without a camera byreturning a null value. The Tiny Flashlight appgracefully handles the revocation of the camerapermission by falling back to the screen-based flash-light solution.(b) Enforcing fine-grained permissionsBesides the revocation of existing permissions, itis also possible to design fine-grained permissionsthat restrict the access of third-party apps. Thesepermissions can add new restrictions to a function-ality that is not yet limited by the current permis-sion system and to a functionality that is alreadyprotected, but not in the desired way. Here, again,the Internet permission is a good example. Fromthe user’s point of view, most apps should onlycommunicate with a limited set of servers.The wetter.com app provides weather informa-

tion and should only communicate with its serversto query weather information. The InternetPolicyof AppGuard provides fine grained Internet accessenabling a consequent white-listing of web serverson a per-app basis. For this particular app we re-strict the Internet access as illustrated in the firstcase study and extend it with regular-expression-based white-listing: ^(.+\.)?wetter\.com$. Similarto the Tiny Flashlight app, no more advertisementsare shown while the application’s core functionalityis preserved. The refined Internet policy can alsobe applied in a general setting as the white-listingcan be configured in the management interface bychoosing from a list of hosts the app has tried toconnect to in the past.(c) Enforcing complex and stateful policiesStateless permissions, as discussed in the previouscase studies, cannot be used to enforce policies thatdepend on the trace of the current execution. UsingAppGuard it is also possible to implement complexstateful policies, e.g. to limit the number of textmessages or phone calls to costly numbers, or to

10

block the Internet access after sensitive informationlike contacts or calendar entries has been accessed.The Post mobil app provided by the Ger-

man postal service Deutsche Post offers, besidesinformative services, the possibility to buystamps online via premium service calls ortext messages. To limit the cost incurred bythis application, it is necessary to track thenumber of previous calls. AppGuard tracksthese numbers and provides the CostPolicy thatlimits the number of possible charges. Wemonitor the relevant function calls for sendingtext messages and for making phone calls, e.g.android.telephony.SmsManager.sendTextMessage().In order to monitor the start of phone calls, itis necessary to track so-called Intents, Android’smessage format for inter- and intra-app commu-nication. Intents contain two parts, an actionto be performed and parameter data encodedas URI. For example, intents that start phonecalls have the action ACTION_CALL. We trackintents by monitoring intent dispatch methods likeandroid.app.Activity. startActivity (Intent).(d) Quick-fixes for vulnerabilities in third-party appsOur system can also fix vulnerabilities in third-party applications. As an example, some appli-cations still transmit sensitive information over theInternet via the http protocol. Although most appsuse encrypted https for the login procedures toweb servers, there are still some applications thatreturn to unencrypted http after successful login,thereby transmitting their authentication tokens inplain text over the Internet. Attackers could eaves-drop on the connection to impersonate the currentuser [36].The Endomondo Sports Tracker uses the https

protocol for the login procedure only, and returnsto the http protocol afterwards, which transmitsthe unencrypted authentication token. As the Webserver supports https for the whole session, theHttpsRedirectPolicy of AppGuard enforces the us-age of https connections throughout the session(cf. Fig. 3), which protects the user’s account anddata from identity theft. Instead of opening an httpconnection, we open an https connection (cf. themonitored method invocations in the first casestudy). Depending on the monitored function, weeither return the redirected https connection, or thecontent from the redirected connection.(e) Mitigation for operating system vulner-abilities

We also found our tool useful to mitigate operat-ing system vulnerabilities. As we cannot changethe operating system itself, we instrument all ap-plications with a global security policy to preventexploits.Case study: Access to photos without a permissionA recent example for an operating system vulnera-bility is the lack of protection of the user’s photoson Android phones. Any application can accessthese photos on the phone without any permissioncheck [10]. Together with the Internet permission,an app could copy all photos to arbitrary servers onthe Internet. This was demonstrated by a proof-of-concept exploit that – disguised as an inconspicu-ous timer app – uploads the user’s personal photosto a public photo sharing site.Android stores photos in a central media store,

that can be accessed via the ContentResolver ob-ject, similar to contact data in the first case study.Leveraging the MediaStorePolicy, we block accessto the stored photos, successfully preventing theexploit.Case study: Local cross-site scripting attackSimilar to the mitigation of the photo access bug,it is also possible to fix security vulnerabilities incore applications that cannot be inlined directly.The Android browser that comes with all devicesis vulnerable to a local cross-site scripting attack [3]up to Android version 2.3.4.If the Android browser receives VIEW intents

from another app with an http/https URI, it opensa new browser window and loads the requested website. Similarly, it also handles VIEW intents witha javascript : URI, however, up to Android version2.3.4, the browser reuses the currently active win-dow. Consequently, the JavaScript code given inthe intent will be executed in the context of thecurrent web site, which leads to a local cross-sitescripting vulnerability.This attack can be mitigated by disallowing this

combination of intents. The InternetPolicy moni-tors startActivity (Intent) calls and throws an ex-ception if the particular intent is not allowed. Thesame approach can be leveraged to preclude third-party apps with no Internet permission from usingintents with an http/https URI to send data to ar-bitrary servers on the Internet.

4.3 Discussion

The presented framework solves a pressing secu-rity problem of the Android platform. Coarse-

11

grained and static policies like the access controlmechanism of Android open the door for silentprivacy violations and trojan horses, as the usernever sees what an application actually does withthe requested permissions. Our fine-grained dy-namic policies can, e.g., be used to distrust the appand only grant a permission once the user findsthat the app does not perform as expected. Thelogging-based approach in our tool allows a user tosee which API calls were denied, possibly with thevalue of significant parameters. Granting access tothose calls that are deemed necessary with restric-tions on parameters (like accessible host names)will eventually lead to a minimal set of permissionsthat fulfills the privacy and security needs of a user.We demonstrated that our solution is practical,

as the runtime overhead and the increase in pack-age sizes are negligible. The actual runtime over-head obviously depends on the complexity of thepolicy. However, when a policy denies access, theprogram will in general take a different executionpath that usually leads to shorter times. The userexperience does not suffer from rewriting the appli-cation. In particular, we did not notice any delaysusing the rewritten app. The rewriting process pro-ceeds fast even on the limited hardware of a mobilephone. The inlining time is already reasonable, butwe still see a large potential for reducing this timewith some optimizations.We outline some challenges and future work in

the following: We currently do not monitor anycode outside of the classes .dex file, in particularwe might miss code in native libraries accessed viaJava’s Native Interface (JNI), dynamically loadedclasses (from external sources), and external pro-grams accessed via inter-procedure calls.Android programs are multi-threaded by default.

Issues of thread safety could therefore arise in themonitor. While we do not yet offer policies thattake the relative timing of method calls in differentthreads into account, we plan to extend our systemto support race-free policies [13] in the future.

5 Related Work

Since the release of Android in 2008, researchershave worked on various security aspects of thisoperating system and proposed many security en-hancements.One line of work analyzed Android’s permission

based access control system. Barrera et al. [4] haveconducted an empirical analysis of Android’s per-

mission system on 1,100 Android applications andsuggested improvements to its granularity. In 2011,Felt et al. [25] analyzed the effectiveness of ap-plication permissions using case studies on GoogleChrome extensions and Android apps.The inflexible and coarse-grained permission sys-

tem of Android inspired many researchers to pro-pose extensions. In 2009, Ongtang et al. [40] ex-tended the current permission system for inter-appcommunication in a system called Saint. Enck etal. [20] introduce a policy based system called Kirinto detect malware candidates at install time basedon an app’s permissions. In 2010, Ongtang et al.introduce a policy-based system called Porscha [39]for digital rights management on smartphones.Nauman et al. [38] present a modification of theAndroid software stack called Apex that enablesdynamic permission revocations. Conti et al. [12]go one step further and integrate with CRePE acontext-related policy enforcement mechanism tothe Android software stack. Grace et al. [31] detectcapability leaks on Android by analyzing phoneimages of different vendors. In contrast to ourapproach, none of these approaches combines afine-grained stateful policy enforcement mechanismwith the ability to deploy the system to unmodifiedstock Android phones.Another open problem of the Android system is

the lack of completeness of its documentation. Us-ing automated testing techniques Felt et al. showthat the mapping of permissions to API-calls isonly insufficiently documented [24]. Even for hon-est developers it is quite difficult to implementapps according to the principle of least privilege.Their analysis showed that roughly one-third of thetested applications were over-privileged. Vidas etal. [46] assist Eclipse developers to follow the prin-ciple of least privilege when programming Androidapps.Further, some papers focus on problems arising

from inter-app communication. Davi et al. [14]demonstrate privilege escalation attacks on An-droid. These attacks are possible when an app ex-poses permission protected functionality via an in-terface (intentionally or unintentionally) to an appwithout the permission. Felt et al. modify theAndroid framework to inspect inter-process com-munication and to mitigate this problem [26]. Di-etz et al. [16] and Bugiel et al. [7] address privi-lege escalation attacks as well. In the latter paper,the authors show how their approach even detectsSoundcomber, a Android trojan based on covert

12

channels [44]. Bugiel et al. have recently extendedtheir framework to additionally detect colludingapps that aim at an intentional privilege escala-tion [8].The concept of inlined reference monitors has re-

ceived considerable attention in the literature. Itwas first formalized by Erlingsson and Schneider inthe development of the SASI/PoET/PSLang sys-tems [23, 22], which implement IRM’s for x86 as-sembly code and Java bytecode. Several other IRMimplementations for Java followed. Polymer [6] isa IRM system based on edit automata, which sup-ports composition of complex security policies fromsimple building blocks. The Java-MOP [11] systemoffers policy-writers a rich set of formal policy spec-ification languages. SPoX [33] enforces declarativeaspect-oriented security policies by rewriting Javabytecode. IRM systems have also been developedfor other platforms. Mobile [34] is an extension toMicrosoft’s .NET Common Intermediate Language(CIL) that supports certified inlined reference mon-itoring. Finally, the S3MS.NET Run Time Mon-itor [15] enforces security policies expressed in avariety of policy languages for .NET desktop andmobile applications on Windows phones.

6 Conclusions

We have presented a practical approach to over-come Android’s limitations regarding secure, user-driven permission management. The system isbased on an inline reference monitor and can bedeployed to all Android devices as it does not relyon modifying the firmware. Most prominently, thesystem can curb the pervasive overly curious behav-ior of Android apps. Apart from that, we are ableto enforce complex stateful security policies andmitigate vulnerabilities of both third-party apps aswell as the OS. Our experimental analysis demon-strates that the overhead of both space and runtimeare negligible. Further, the case studies illustratethe prevention of several real-world attacks on An-droid vulnerabilities.

7 Acknowledgements

This work was supported by the German Ministryfor Education and Research (BMBF) through fund-ing for the Center for IT-Security, Privacy and Ac-countability (CISPA) and both the initiative forexcellence and the Emmy Noether program of the

German federal government. Further, we wouldlike to thank Bastian Könings for pointing us tointeresting Android apps.

References[1] Android.com: Philosophy and Goals | Android

Open Source (2010), http://source.android.com/about/philosophy.html

[2] Android.com: Security and Permissions(2012), http://developer.android.com/guide/topics/security/security.html

[3] Backes, M., Gerling, S., von Styp-Rekowsky,P.: A Local Cross-Site Scripting At-tack against Android Phones (2011),http://www.infsec.cs.uni-saarland.de/projects/android-vuln/android_xss.pdf

[4] Barrera, D., Kayacık, H.G., van Oorschot,P.C., Somayaji, A.: A Methodology for Em-pirical Analysis of Permission-Based SecurityModels and its Application to Android. In:Proc. 17th ACM Conference on Computer andCommunication Security (CCS 2010). pp. 73–84 (2010)

[5] Bauer, L., Ligatti, J., Walker, D.: A Languageand System for Composing Security Policies.Tech. Rep. TR-699-04, Princeton University(January 2004)

[6] Bauer, L., Ligatti, J., Walker, D.: Composingsecurity policies with polymer. In: Proc. ACMSIGPLAN 2005 Conference on ProgrammingLanguage Design and Implementation (PLDI2005). pp. 305–314 (2005)

[7] Bugiel, S., Davi, L., Dmitrienko, A., Fischer,T., Sadeghi, A.R.: XManDroid: A New An-droid Evolution to Mitigate Privilege Escala-tion Attacks. Tech. Rep. TR-2011-04, Technis-che Universität Darmstadt - Cased (2011)

[8] Bugiel, S., Davi, L., Dmitrienko, A., Fis-cher, T., Sadeghi, A.R., Shastry, B.: TowardsTaming Privilege-Escalation Attacks on An-droid. In: Proc. 19th Annual Network and Dis-tributed System Security Symposium (NDSS2011) (2012)

[9] Chaudhuri, A., Fuchs, A., Foster, J.:SCanDroid: Automated Security Certifica-tion of Android Applications. Tech. Rep.

13

CS-TR-4991, University of Maryland, Col-lege Park (2009), http://www.cs.umd.edu/~avik/papers/scandroidascaa.pdf

[10] Chen, B.X., Bilton, N.: Et Tu, Google? An-droid Apps Can Also Secretly Copy Pho-tos (2012), http://bits.blogs.nytimes.com/2012/03/01/android-photos/

[11] Chen, F., Roşu, G.: Java-MOP: A Monitor-ing Oriented Programming Environment forJava. In: Proc. 11th International Conferenceon Tools and Algorithms for the constructionand analysis of systems (TACAS 2005). vol.3440, pp. 546–550. Springer-Verlag (2005)

[12] Conti, M., Nguyen, V.T.N., Crispo, B.:CRePE: Context-Related Policy Enforcementfor Android. In: Proc. 13th International Con-ference on Information Security (ISC 2010).pp. 331–345 (2010)

[13] Dam, M., Jacobs, B., Lundblad, A., Piessens,F.: Security Monitor Inlining and Certifi-cation for Multithreaded Java. MathematicalStructures in Computer Science (2011)

[14] Davi, L., Dmitrienko, A., Sadeghi, A.R.,Winandy, M.: Privilege Escalation Attacks onAndroid. In: Proc. 13th International Confer-ence on Information Security (ISC 2010). pp.346–360 (2010)

[15] Desmet, L., Joosen, W., Massacci, F., Nal-iuka, K., Philippaerts, P., Piessens, F.,Vanoverberghe, D.: The S3MS.NET RunTime Monitor. Electron. Notes Theor. Com-put. Sci. 253(5), 153–159 (Dec 2009)

[16] Dietz, M., Shekhar, S., Pisetsky, Y., Shu, A.,Wallach, D.S.: QUIRE: Lightweight Prove-nance for Smart Phone Operating Systems. In:Proc. 20th Usenix Security Symposium (2011)

[17] von Eitzen, C.: Apple: Future iOS release willrequire user permission for apps to access ad-dress book (February 2012), http://h-online.com/-1435404

[18] Enck, W., Gilbert, P., Chun, B.G., Cox, L.P.,Jung, J., McDaniel, P., Sheth, A.N.: Taint-Droid: An Information-Flow Tracking Systemfor Realtime Privacy Monitoring on Smart-phones. In: Proc. 9th Usenix Symposium onOperating Systems Design and Implementa-tion (OSDI 2010). pp. 393–407 (2010)

[19] Enck, W., Octeau, D., McDaniel, P., Chaud-huri, S.: A Study of Android Application Se-curity. In: Proc. 20th Usenix Security Sympo-sium (2011)

[20] Enck, W., Ongtang, M., McDaniel, P.: Onlightweight mobile phone application certifi-cation. In: Proc. 16th ACM Conference onComputer and Communication Security (CCS2009). pp. 235–245 (2009)

[21] Erlingsson, Ú.: The Inlined Reference Mon-itor Approach to Security Policy Enforce-ment. Ph.D. thesis, Cornell University (Jan-uary 2004)

[22] Erlingsson, Ú., Schneider, F.B.: IRM Enforce-ment of Java Stack Inspection. In: Proc. 2002IEEE Symposium on Security and Privacy(Oakland 2002). pp. 246–255 (2000)

[23] Erlingsson, U., Schneider, F.B.: SASI enforce-ment of security policies: a retrospective. In:Proc. of the 1999 workshop on New securityparadigms (NSPW 1999). pp. 87–95 (2000)

[24] Felt, A.P., Chin, E., Hanna, S., Song, D., Wag-ner, D.: Android Permissions Demystified. In:Proc. 18th ACM Conference on Computer andCommunication Security (CCS 2011) (2011)

[25] Felt, A.P., Greenwood, K., Wagner, D.: TheEffectiveness of Application Permissions. In:Proc. 2nd Usenix Conference on Web Appli-cation Development (WebApps 2011) (2011)

[26] Felt, A.P., Wang, H.J., Moshchuk, A., Hanna,S., Chin, E.: Permission Re-Delegation: At-tacks and Defenses. In: Proc. 20th Usenix Se-curity Symposium. pp. Want to prevent per-mission re–delegation attacks. (2011)

[27] Gartner: Gartner Says Worldwide Smart-phone Sales Soared in Fourth Quarter of2011 With 47 Percent Growth, http://www.gartner.com/it/page.jsp?id=1924314

[28] Gibler, C., Crussel, J., Erickson, J., Chen,H.: AndroidLeaks: Detecting Privacy Leaks inAndroid Applications. Tech. Rep. CSE-2011-10, University of California Davis (2011)

[29] Gilbert, P., Chun, B.G., Cox, L.P., Jung, J.:Vision: Automated Security Validation of Mo-bile Apps at App Markets. In: Proc. 2nd In-ternational Workshop on Mobile Cloud Com-puting and Services (MCS 2011 (2011)

14

[30] Google Play (2012), https://play.google.com/store

[31] Grace, M., Zhou, Y., Wang, Z., Jiang, X.:Systematic Detection of Capability Leaks inStock Android Smartphones. In: Proc. 19thAnnual Network and Distributed System Se-curity Symposium (NDSS 2011) (2012)

[32] Gruver, B.: Smali: A assembler/disassemblerfor Android’s dex format, http://code.google.com/p/smali/

[33] Hamlen, K.W., Jones, M.: Aspect-oriented in-lined reference monitors. In: Proc. 3rd ACMSIGPLAN Workshop on Programming Lan-guages and Analysis for Security (PLAS 2008).pp. 11–20 (2008)

[34] Hamlen, K.W., Morrisett, G., Schneider, F.B.:Certified In-lined Reference Monitoring on.NET. In: Proc. 1st ACM SIGPLAN Work-shop on Programming Languages and Analy-sis for Security (PLAS 2006). pp. 7–16 (2006)

[35] Hornyack, P., Han, S., Jung, J., Schechter,S., Wetherall, D.: ”These Aren’t the DroidsYou’re Looking For”: Retrofitting Android toProtect Data from Imperious Applications. In:Proc. 18th ACM Conference on Computer andCommunication Security (CCS 2011) (2011)

[36] Könings, B., Nickels, J., Schaub, F.: CatchingAuthTokens in the Wild - The Insecu-rity of Google’s ClientLogin Protocol.Tech. rep., Ulm University (2011), http://www.uni-ulm.de/in/mi/mi-mitarbeiter/koenings/catching-authtokens.html

[37] Ligatti, J., Bauer, L., Walker, D.: Edit Au-tomata: Enforcement Mechanisms for Run-time Security Policies. International Journalof Information Security 4(1–2), 2–16 (2005)

[38] Nauman, M., Khan, S., Zhang, X.: Apex: Ex-tending Android Permission Model and En-forcement with User-defined Runtime Con-straints. In: Proc. 5th ACM Symposium onInformation, Computer and CommunicationSecurity (ASIACCS 2010). pp. 328–332 (2010)

[39] Ongtang, M., Butler, K.R.B., McDaniel, P.D.:Porscha: policy oriented secure content han-dling in Android. In: Proc. 26th Annual Com-puter Security Applications Conference (AC-SAC 2010). pp. 221–230 (2010)

[40] Ongtang, M., McLaughlin, S.E., Enck, W.,McDaniel, P.: Semantically Rich Application-Centric Security in Android. In: Proc. 25thAnnual Computer Security Applications Con-ference (ACSAC 2009). pp. 340–349 (2009)

[41] Portokalidis, G., Homburg, P., Anagnostakis,K., Bos, H.: Paranoid Andoird: Versatile Pro-tection For Smartphones. In: Proc. 26th An-nual Computer Security Applications Confer-ence (ACSAC 2010). pp. 347–356 (2010)

[42] Rubin, A.: Google+ post on the Androidecosystem (2012), https://plus.google.com/u/0/112599748506977857728/posts/Btey7rJBaLF

[43] Sarno, D.: Twitter stores full iPhone contactlist for 18 months, after scan (February 2012),http://articles.latimes.com/2012/feb/14/business/la-fi-tn-twitter-contacts-20120214

[44] Schlegel, R., Zhang, K., Zhou, X., Intwala,M., Kapadia, A., Wang, X.: Soundcomber: AStealthy and Context-Aware Sound Trojan forSmartphones. In: Proc. 18th Annual Networkand Distributed System Security Symposium(NDSS 2011). pp. 17–33 (2011)

[45] Schneider, F.B.: Enforceable Security Policies.ACM Transactions on Information and Sys-tem Security 3(1), 30–50 (2000)

[46] Vidas, T., Christin, N., Cranor, L.F.: CurbingAndroid Permission Creep. In: Proc. Work-shop on Web 2.0 Security and Privacy 2011(W2SP 2011) (2011)

15

Original snippetURL url = new URL(loc);URLConnnection conn =url .openConnection();

After inliningURL url = new URL(loc);URLConnection conn;try {MonitorInterface.checkConnection(url);conn = url.openConnection();

} catch (MonitorException e) {conn = (URLConnection) e.value();

}

Figure 4: Illustration of the call-site monitoring code for the security-relevantmethod java .net.URL.openConnection().

16