Efficient, Context-Aware Privacy

Efficient, Context-Aware Privacy Leakage Confinement for Android Applications without Firmware Modding

Mu ZhangHeng Yin

Department of EECS, Syracuse University

1

Motivation: We need a practical solution for privacy leakage confinement in AndroidWhat does a practical solution mean?Information-flow based securityMost of existing solutions are end-point solutionsContext-aware policy enforcementExisting solutions are all-or-nothing protection No firmware moddingAll existing solutions require firmware moddingLow runtime overheadTaint tracking is slow!

2

Capper: Context-Aware Privacy Policy Enforcement with Re-writingKey Techniques

Bytecode Rewriting for Information Flow Tracking and Control

Context-aware Policy Enforcement3

BRIFT: Bytecode Rewriting for Information Flow Tracking and ControlKey: to place minimally required code into a bytecode program to accurately keep track of privacy leakage.

Resources

DEXAndroid AppTranslation

IR

Static Analysis

Slices

Static Instrumentation

New IR

Optimization

Optimized IR

Code Generation

Resources

DEX’

New App

4

BRIFT: Some Technical DetailsStatic Data-flow AnalysisSimilar to CHEX[Lu et al. CCS’12]Discover entry points, compute program splits, and perform permutation on the splitsStatic InstrumentationCreate shadow variables Insert taint propagation statementsPass shadow parameters across function boundaryOptimizationRemove unnecessary shadow parametersLift taint propagation logic into the function caller

Other built-in optimizations, such as constant propagation, dead code elimination, etc. 5

BRIFT: A Running Example 1

public

class Leakage extends Activity{ 2 private byte key = DEFAULT_KEY;

3

private

String

addr

= DEFAULT_ADDR;

4

private

static

String

deviceId

;

5

6

public

String

getIMEI

(){

7

TelephonyManager

manager = (

TelephonyManager

)

getSystemService

(

“phone”

);

8 String

imei

=

manager.getDeviceId

();

9

if

(

imei

==null){

10

imei

=

“”

;

11 }

else

{

12

imei

=

manager.getDeviceId

();

13 }

14

return

imei

;

15 }1617 public byte crypt(byte plain){18 return (byte)(plain ^ key);19 } 2021 public void post(String addr, byte[] bytes){22 OutputStream output = conn.getOutputStream();23 output.write(bytes, 0, bytes.length); ... }2627 public void toastIMEI(String imei){28 Context app = getApplicationContext();29 String text = “Your IMEI is ” + imei;30 int duration = Toast.LENGTH_SHORT;31 Toast toast = Toast.makeText(app, text, duration); toast.show();33 }

3435 public void onStart(){36 Leakage.deviceId = getIMEI();37 } 3839 public void onResume(){40 toastIMEI(Leakage.deviceId);41 }4243 public void onDestroy(){44 String imei = Leakage.deviceId;45 byte[] bytes = location.getBytes();46 for(int i=0; i<bytes.length; i++)47 bytes[i] = crypt(bytes[i]);48 }49 post(addr, bytes);50 }}

6

BRIFT: the Rewritten Program71

public

class Leakage extends Activity{ ...4 private static

String

deviceId

;

I

public

static

boolean

deviceId_s0_t;

...

6

public

String

getIMEI

(

BoolWrapper

ret_s0_wrapper

){

...

8

String

imei

=

manager.getDeviceId

();

9

if

(

imei

==null){

10

i

mei

=

“”

;

I

imei_s0_t

=

false

;

}

else

{

imei

=

manager.getDeviceId

();

I

imei_s0_t

=

true

;

}

I ret_s0_wrapper.status = imei_s0_t;14 return imei;15 } ...21 public void post(String addr, byte[] bytes, BoolWrapper bytes_s0_w){I boolean bytes_s0_t = bytes_s0_wrapper.status; OutputStream output = conn.getOutputStream();I boolean isAllow = false;I if(bytes_s0_t == true)I isAllow = queryPolicyService(0, 0, addr);I

if(isAllow) output.write(bytes, 0, bytes.length);}I else{...} ... } ...35 public void onStart(){I BoolWrapper ret_s0_wrapper = new BoolWrapper();I ret_s0_wrapper.status = false; Leakage.deviceId = getIMEI(ret_s0_wrapper);I Leakage.deviceId_s0_t = ret_s0_wrapper.status;37 } ... 43 public void onDestroy(){44 String imei = Leakage.deviceId;45 byte[] bytes = imei.getBytes();I boolean bytes_s0_t = Leakage.deviceId_s0_t;46 for(int i=0,;

i

<

b

ytes.length

; i++){47 bytes[i] = crypt(bytes[i]);I bytes_s0_t = bytes_s0_t || false;48 }I BoolWrapper bytes_s0_wrapper = new BoolWrapper();I bytes_s0_wrapper.status = bytes_s0_t;P BoolWrapper url_s0_w = new BoolWrapper();49 post(addr, bytes, bytes_s0_wrapper);50 }51 }

See more details in our NDSS’14 paper

Context-Aware Policy: How to model the context of an information flowTaint Propagation TraceHeavy-weightOverly preciseSource and Sink Call-sitesLight-weightMimicry attack?Parameterized Source and Sink Pairs8

Evaluation: Overview4723 apps real-world apps evaluated1414 (33%) are risky (may leak information)Increase of Program SizeRuntime Performance of Analysis and RewritingRuntime OverheadEffectiveness9

Related WorkExtend install-time constraintsKirin, CCS’09; Saint, ACSAC’09Enforce finer-grained/flexible permissionsMockDroid, HotMobile’11; CRePE, ISC’10

; Apex, ASIACCS’10; TISSA, TRUST’11Improve isolationsCells, SOSP’11; SPSM’11

; AdSplit, Usenix Security’12Ask for user approvalLivshits and Jung, Usenix Security’13; Aurasium, Usenix Security’12Information flow based solutionTaintDroid, OSDI’10; AppFence, CCS’1110

Conclusion: We achieved four goalsG1: Information-flow based security Yes, we track sensitive information flow by rewritingG2: Context-aware policy enforcement Yes, we model the context of an information flow, and bind this context with user’s decisionG3: No firmware modding Yes, we only rewrite apps and install a policy serviceG4: Low runtime overhead Yes, we only insert a minimal amount of code to keep track of sensitive information flow

11

Questions?12

Related Work[1] W. Enck, M. Ongtang, and P. McDaniel. On Lightweight Mobile Phone Application Certification. In Proceedings of CCS’09.[2] M. Ongtang, S. McLaughlin, W. Enck, and P. McDaniel. Semantically Rich Application-Centric Security in Android. In Proceedings of ACSAC’09.[3] A. R. Beresford, A. Rice, N. Skehin

, and R. Sohan. MockDroid: Trading Privacy for Application Functionality on Smartphones. In Proceedings of HotMobile’11.[4] M. Conti, V. T. N. Nguyen, and B.

Crispo. CRePE: Context-Related Policy Enforcement for Android. In Proceedings of ISC’10.[5] M. Nauman, S. Khan, and X. Zhang. Apex: Extending Android Permission Model and Enforcement with User-defined Runtime Constraints. In Proceedings of ASIACCS’10.[6] Y. Zhou, X. Zhang, X. Jiang, and V. W. Freeh. Taming Information-Stealing Smartphone Applications (on Android). In Proceedings of TRUST’11.[7] J. Andrus, C. Dall, A. V. Hof, O. Laadan, and J. Nieh. Cells: A Virtual Mobile Smartphone Architecture. In Proceedings of SOSP’11.[8] M. Lange, S. Liebergeld, A. Lackorzynski, A. Warg, and M. Peter. L4Android: A Generic Operating System Framework for Secure Smartphones. In Proceedings of SPSM’11.[9] S. Shekhar, M. Dietz, and D. S. Wallach. AdSplit: Separating Smartphone Advertising from Applications. In Proceedings of Usenix Security ’12.[10] B. Livshits and J. Jung. Automatic Mediation of Privacy-Sensitive Resource Access in Smartphone Applications. In Proceedings of Usenix Security’13.[11] R. Xu, H. Saïdi, and R. Anderson. Aurasium: Practical Policy Enforcement for Android Applications. In Proceedings of USENIX Security’12.[12] W. Enck, P. Gilbert, B.-G. Chun, L. P. Cox, J. Jung, P. McDaniel, and A. N. Sheth. TaintDroid: An Information-Flow Tracking System for Realtime

Privacy Monitoring on

Smartphones

. In Proceedings of OSDI’10.

[13] P.

Hornyack

, S. Han, J. Jung, S. Schechter, and D.

Wetherall

. These Aren’t The Droids You’re Looking For:

Retrofitting

Android to Protect Data from Imperious Applications. In Proceedings CCS’11.

13