The Impact of Vendor Customizations on Android

SecurityLei Wu, Michael Grace, Yajin Zhou,

Chiachih Wu, Xuxian JiangDepartment of Computer Science

North Carolina State UniversityCCS 2013

Outline Introduction Design

• Provenance Analysis• Permission Usage Analysis• Vulnerability Analysis

Reachability Analysis Reflection Analysis

Outline(cont) Implementation and evaluation

• Provenance Analysis• Permission Usage Analysis• Vulnerability Analysis

Discussion Related work Conclusion

Introduction Ten representative stock Android

images Five popular smartphone vendors To assess the extent of security

issues

Introduction 482.5 million sold in the Q4 of 2012

• 70% global market share Android open source project (AOSP) Vendor customizations Third party apps: vendors or carriers Three stage process

• Stock images: provenance analysis• permission usages of pre-load apps: unnecessary

permission request• Pre-load apps vulnerabilities analysis: permission re-

delegation attack and private information leakage

Introduction SEFA: Security Evaluation Framework for

Android Evaluation result: worrisome

• 81.78% pre-load apps are from vendor customizations

• 85.78% pre-load apps are over privileged, majority of them are from vendor customizations ?

• 64.71% to 85.00% vulnerabilities are from vendor customization(Samsung, HTC, LG, except for Sony).

• Current HTC is more secure than before.

Design: SEFA Architecture of SEFA

Design: Provenance Analysis Provenance Analysis

• AOSP app: Android open source project. Original apps of Android

• Vendor app: identified by signatures Apps developed by venders.

• Third-party app: identified by signatures Apps developed by third-parties.

Exceptions• AOSP app may be modified by venders.

SONY Conversation app vs AOSP Mms app

Design: Provenance Analysis SEFA determines AOSP procedure:

• By matching app and package names• By matching component names in the manifest file.• By calculating the similarity between paths and

apps. Path: sequence of methods from entry point into a sink Sink: operation requiring dangerous and sensitive

permissions Static analysis

• Baksmali• Firmware release and update information

Design: Permission Usage Analysis

Permission overprivilege• Initial permission set of apps• Step1

To generate the complete requested permission set: R-set Initial requested permission set from manifest files of apps To include shared permission set: SharedUserId

• Step2 To calculate the used permission set: U-set

Used by API invocations Used by Intents Used by content providers

• Step3: The overprivilege set: R–U

Design: Permission Usage Analysis

Algorithm 1 Initial R set

To generate the complete R set

To generate the U set

To generate the permission

overprivilege set

Design: Vulnerability Analysis Vulnerabilities:

• Permission re-delegation attack Aims at using for dangerous actions

• Passive content leak: world readable content provider • Content pollution: world writable content provider

Aims at serious content leak Find the paths

• From open entrypoints to sinks Sensitive-sinks: APIs to sensitive permissions Bridge-sinks: invocations indirectly another components

In-component: reachability analysis Cross-component: reflection analysis

Design: Reachability Analysis To determine the feasible paths from the entrypoint

set of all Android components. Step1: intra-procedural reachability analysis

• building the call graphs and resolve it by using def-use analysis

• The resolution starts rom the initial state to seek for a fix point of state changes with iteration

• The result of states of variables and fields is named as a “summary”

Step2: inter-procedural reachability analysis• Propagate the states among different methods• Re-issue step1 if the summary is changed.

Feasible path: execution flow

Design: Reachability Analysis

Algorithm Appendix• Execution flow

Check the summary of

each callee c is modified or notinvoking

inter-analysis related to c

(????)

????

Design: Reflection Analysis Reflection attack: Example Vulnerability paths

• in-component: reachability analysis From unprotected component to a sink located in the

same component• cross-component: none

From unprotected component to a sink located in the different component but in the same app

• cross-app: none From unprotected component to a sink located in the

different component in the different app Reflection analysis: to find all possible

connections among components/apps

Design: Reflection Analysis Algorithm 2: reflection analysis

• For current component and visited component list: If current component is visited, return with V Or append current component into visited

component list. If this current component is vulnerable, add

to V• For all other components able to start

current component Do reflection analysis among them

• Return V

Add to V if c is vulnerable

Implementation and Evaluation

SEFA was written in Java and Python Processing time of each image:70

min avg. Manual verify of vulnerabilities Baksmali

Implementation and Evaluation

Devices 2010-2012

Implementation and Evaluation

Permission Usage Analysis• % of Overprivilege apps

87.96% -> 83.61%: avg.: 85.78%

Implementation and Evaluation

Vulnerabilities• % of vulnerable apps

Worst in %: HTC wildfire S, LG Optimus P880

Implementation and Evaluation

Vulnerabilities: customizations• Customizations: vender and

third-parties• % of vulnerable apps of

customizations

Implementation and Evaluation

Vulnerabilities• Inherited: from previous product • Introduced: new found in the new

product

Implementation and Evaluation

Vulnerabilities• Critical vulnerabilities• Other: vendor- or model- specific

Implementation and Evaluation

Vulnerabilities: cross-app vulnerabilities• Difficult to detect• % of cross-app vulnerabilities

Case study: Samsung S3 Reflection attack sample Pre-load app: Keystring_misc

• Protected component:PhoneUtilReceiver• Permission:

com.sec.android.app.phoneutil.permission• systemOrSignature level

Another app: FactoryTest• Feasible path: able to start this component

of Keystring_misc• Cross app vulnerability path

Two hard-coded local socket:FactoryClientRecvFactoryClientSendAble to receive command from local socket

Protected

Case study: Samsung S3 sCloudBackupProvider app

• Four content providers in the app with package name: Com.sec.android.sCloudBackupProvider

• Exposing access interfaces to databases Calllogs.db, sms.db, mms.db, settings.db

• Interfaces are protected by two normal-level permissions

• Able to be accessed by any third-party app

Discussion Software development policies

• Sony• HTC

Popular product vs poor security level• Samsung S3

Limitations • Not cover customization of system level code• High false positive rate of analysis

Manually verify avg. 300 paths per device• It would be better to use dynamic analyzer

Related work Provenance Analysis

• SMIT: malware database• DroidMOSS, DNADroid, PiggyApp: detecting

repackaging app in markets. Permission Usage Analysis

• Pscout: overprivilege apps Vulnerability Analysis

• DroidRanger: detect malicious app in markets• TaintDroid, MockDroid, TISSA: privacy leaks• ComDroid, Woodpecker, CHEX: in-component

vulnerability detection

Conclusion Evaluate the security impact of

vender customizations Overprivilege app analysis Static reachability and reflection

analysis