The impact of vendor customizations on android security
1 / 29

The Impact of Vendor Customizations on Android Security - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' The Impact of Vendor Customizations on Android Security' - peony

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
The impact of vendor customizations on android security

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

Outlin e

  • 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

I ntroduction

Ten representative stock Android images

Five popular smartphone vendors

To assess the extent of security issues


  • 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


  • 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
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 analysis1
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
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 analysis1
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
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
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 analysis1
Design: Reachability Analysis

Check the summary of each callee c is modified or not


inter-analysis related to c (????)


  • Algorithm Appendix

    • Execution flow

Design reflection analysis
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 analysis1
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
Implementation and Evaluation

SEFA was written in Java and Python

Processing time of each image:70 min avg.

Manual verify of vulnerabilities


Implementation and evaluation2
Implementation and Evaluation

  • Permission Usage Analysis

    • % of Overprivilege apps

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

Implementation and evaluation3
Implementation and Evaluation

  • Vulnerabilities

    • % of vulnerable apps

      • Worst in %: HTC wildfire S, LG Optimus P880

Implementation and evaluation4
Implementation and Evaluation

  • Vulnerabilities: customizations

    • Customizations: vender and third-parties

    • % of vulnerable apps of customizations

Implementation and evaluation5
Implementation and Evaluation

  • Vulnerabilities

    • Inherited: from previous product

    • Introduced: new found in the new product

Implementation and evaluation6
Implementation and Evaluation

  • Vulnerabilities

    • Critical vulnerabilities

    • Other: vendor- or model- specific

Implementation and evaluation7
Implementation and Evaluation

  • Vulnerabilities: cross-app vulnerabilities

    • Difficult to detect

    • % of cross-app vulnerabilities

Case study s amsung s3
Case study: Samsung S3

Two hard-coded local socket:



Able to receive command from local socket


  • Reflection attack sample

  • Pre-load app: Keystring_misc

    • Protected component:PhoneUtilReceiver

    • Permission:

    • systemOrSignature level

  • Another app: FactoryTest

    • Feasible path: able to start this component of Keystring_misc

    • Cross app vulnerability path

Case study samsung s3
Case study: Samsung S3

  • sCloudBackupProvider app

    • Four content providers in the app with package name:


    • 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


  • 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
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


Evaluate the security impact of vender customizations

Overprivilege app analysis

Static reachability and reflection analysis