290 likes | 460 Views
The Impact of Vendor Customizations on Android Security. Lei Wu, Michael Grace, Yajin Zhou , Chiachih Wu, Xuxian Jiang Department of Computer Science North Carolina State University CCS 2013. Outlin e. Introduction Design Provenance Analysis Permission Usage Analysis
E N D
The Impact of Vendor Customizations on Android Security Lei Wu, Michael Grace, Yajin Zhou, ChiachihWu, Xuxian Jiang Department of Computer Science North Carolina State University CCS 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 securethan 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 Initial R set To generate the complete R set To generate the U set To generate the permission overprivilege set Algorithm 1
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 Check the summary of each callee c is modified or not invoking inter-analysis related to c (????) ???? • Algorithm Appendix • Execution flow
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 • Add to V if c is vulnerable • 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
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 Two hard-coded local socket: FactoryClientRecv FactoryClientSend Able to receive command from local socket Protected • 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
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