1 / 29

The Impact of Vendor Customizations on Android Security

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

peony
Download Presentation

The Impact of Vendor Customizations on Android Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. Outline • Introduction • Design • Provenance Analysis • Permission Usage Analysis • Vulnerability Analysis • Reachability Analysis • Reflection Analysis

  3. Outline(cont) • Implementation and evaluation • Provenance Analysis • Permission Usage Analysis • Vulnerability Analysis • Discussion • Related work • Conclusion

  4. Introduction Ten representative stock Android images Five popular smartphone vendors To assess the extent of security issues

  5. 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

  6. 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.

  7. Design:SEFA Architecture of SEFA

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

  14. Design: Reachability Analysis Check the summary of each callee c is modified or not invoking inter-analysis related to c (????) ???? • Algorithm Appendix • Execution flow

  15. 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

  16. 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

  17. Implementation and Evaluation SEFA was written in Java and Python Processing time of each image:70 min avg. Manual verify of vulnerabilities Baksmali

  18. Implementation and Evaluation Devices 2010-2012

  19. Implementation and Evaluation • Permission Usage Analysis • % of Overprivilege apps • 87.96% -> 83.61%: avg.: 85.78%

  20. Implementation and Evaluation • Vulnerabilities • % of vulnerable apps • Worst in %: HTC wildfire S, LG Optimus P880

  21. Implementation and Evaluation • Vulnerabilities: customizations • Customizations: vender and third-parties • % of vulnerable apps of customizations

  22. Implementation and Evaluation • Vulnerabilities • Inherited: from previous product • Introduced: new found in the new product

  23. Implementation and Evaluation • Vulnerabilities • Critical vulnerabilities • Other: vendor- or model- specific

  24. Implementation and Evaluation • Vulnerabilities: cross-app vulnerabilities • Difficult to detect • % of cross-app vulnerabilities

  25. 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

  26. 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

  27. 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

  28. 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

  29. Conclusion Evaluate the security impact of vender customizations Overprivilege app analysis Static reachability and reflection analysis

More Related