Harvesting Inconsistent Security Configurations in Custom Android

Download Harvesting Inconsistent Security Configurations in Custom Android

Post on 14-Feb-2017

213 views

Category:

Documents

0 download

Embed Size (px)

TRANSCRIPT

  • USENIX Association 25th USENIX Security Symposium 1153

    Harvesting Inconsistent Security Configurations in Custom Android ROMsvia Differential Analysis

    Yousra Aafer, Xiao Zhang, and Wenliang DuSyracuse University

    {yaafer, xzhang35, wedu}@syr.edu

    Abstract

    Android customization offers substantially different ex-periences and rich functionalities to users. Every partyin the customization chain, such as vendors and carri-ers, modify the OS and the pre-installed apps to tailortheir devices for a variety of models, regions, and customservices. However, these modifications do not come atno cost. Several existing studies demonstrate that mod-ifying security configurations during the customizationbrings in critical security vulnerabilities. Albeit theseserious consequences, little has been done to systemat-ically study how Android customization can lead to se-curity problems, and how severe the situation is. In thiswork, we systematically identified security features that,if altered during the customization, can introduce poten-tial risks. We conducted a large scale differential analy-sis on 591 custom images to detect inconsistent securityfeatures. Our results show that these discrepancies areindeed prevalent among our collected images. We havefurther identified several risky patterns that warrant fur-ther investigation. We have designed attacks on real de-vices and confirmed that these inconsistencies can indeedlead to actual security breaches.

    1 Introduction

    When vendors, such as Samsung, LG and HTC, put An-droid AOSP OS on their devices, they usually conductextensive customization on the system. The reasons forcustomization can be many, including adding new func-tionalities, adding new system apps, tailoring the devicefor different models (e.g., phone or tablet), or carriers(e.g., T-mobile and AT&T), etc. Further complicatingthe process is Android updates pushed to the devices: theupdates might target a new Android or app version.

    This fragmented eco-system brings in several secu-rity risks when vendors change the functionalities andconfigurations without a comprehensive understanding

    of their implications. Previous work has demonstratedsome aspects of these changes and the resulting risks.Wu et al. [25] analyze several stock Android images fromdifferent vendors, and assess security issues that may beintroduced by vendor customization. Their results showthat customization is responsible for a number of secu-rity problems ranging from over-privileged to buggy sys-tem apps that can be exploited to mount permission re-delegation or content leaks attacks. Harehunter [5] re-veals a new category of Android vulnerabilities, calledHares, caused by the customization process. Hares oc-cur when an attribute is used on a device but the partydefining it has been removed during the customization.A malicious app can impersonate the missing attributeto launch privilege escalation, information leakage andphishing attacks. ADDICTED [29] finds that many cus-tom Android devices do not properly protect Linux de-vice drivers, exposing them to illegitimate parties.

    All the problems reported so far on Android cus-tomization are mainly caused by vendors altering of crit-ical configurations. They change security configurationsof system apps and Linux device drivers; they also re-move, add, and alter system apps. Although the exist-ing work has studied several aspects of security problemsin the changes of system/app configurations, there is nowork that systematically finds all security configurationchanges caused by vendor customization, how likely itcan lead to security problems, what risky configurationchanges are often made by vendors, etc.

    In this work, we make the first attempt to systemat-ically detect security configuration changes introducedby parties in the customization chain. Our key intu-ition is that through comparing a custom device to simi-lar devices from other vendors, carriers, and regions, orthrough comparing different OS versions, we might beable to find security configuration changes created unin-tentionally during the customization. More importantly,through a systematic study, we may be able to find valu-able insights in vendor customization that can help ven-

  • 1154 25th USENIX Security Symposium USENIX Association

    dors improve the security of their future customizations.We propose DroidDiff, a tool that detects inconsistentsecurity configurations in a large scale, and that can beemployed by vendors to locate risky configurations.

    The first challenge that we face in our systematic studyis to identify what configurations are security relevantand are likely to be customized. We start from the An-droid layered architecture and list access control checksemployed at each layer. Then, for each check, we rely onAndroid documentation and our domain knowledge todefine corresponding security features. We further ana-lyze how different configurations of these features acrosscustom images can lead to inconsistencies and thus af-fect the access control check semantics. As a result, wehave identified five categories of features. DroidDiff thenextracts these features from 591 custom Android ROMsthat we collected from multiple sources. This step pro-duces the raw data that will be used for our analysis.

    The next challenge is how to compare these imagesto find out whether they have inconsistent values for thefeatures that we extracted. Given a set of images, con-ducting the comparison itself is not difficult; the diffi-culty is to decide the set of images for comparison. Ifwe simply compare all the 591 images, it will not pro-vide much insight, because it will be hard to interpretthe implications of detected inconsistencies. To gainuseful insights, we need to select a meaningful set ofimages for each comparison. Based on our hypothesisthat inconsistencies can be introduced by vendors, devicemodels, regions, carriers, and OS versions, we devel-oped five differential analysis algorithms: Cross-Vendor,Cross-Model, Cross-Region, Cross-Carrier, and Cross-Version analyses, each targeting to uncover inconsisten-cies caused by customization of different purposes. Forexample, in the Cross-Vendor analysis, we aim to knowhow many inconsistencies are there among different ven-dors; in the Cross-Model analysis, we attempt to identifywhether vendors may further introduce inconsistencieswhen they customize Android for different models (e.g.Samsung S4, S5, S6 Edge).

    DroidDiff results reveal that indeed the customizationprocess leads to many inconsistencies among securityfeatures, ranging from altering the protection levels ofpermissions, removing protected broadcasts definitions,changing the requirement for obtaining critical GIDs,and altering the protection configuration of app compo-nents. We present our discoveries in the paper to showthe inconsistency situations among each category of fea-tures and how versions, vendors, models, region, and car-riers customizations impact the whole situation.

    Not all inconsistencies are dangerous, but somechanges patterns are definitely risky and warrant furtherinvestigation. We have identified such risky patterns,and presented results to show how prevalent they are in

    the customization process. The inconsistencies exposesystems to potential attacks, but if the vendors under-stand fully the implication of such customization, theywill more likely remedy the introduced risks by puttingproper protection at some other places. Unfortunately,most of the inconsistencies seem to be introduced by de-velopers who do not fully understand the security im-plications. Therefore, our DroidDiff can help vendorsto identify the inconsistencies introduced during theircustomization, so they can question themselves whetherthey have implemented mechanisms to remedy the risks.

    To demonstrate that the identified inconsistencies, ifintroduced by mistakes, can indeed lead to attacks, wepicked few cases detected through our differential anal-ysis, and designed proof-of-concept attacks on physicaldevices1. We have identified several real attacks. To il-lustrate, we found that a detected inconsistency on Nexus6 can be exploited to trigger emergency broadcasts with-out the required system permission and another similarone on Samsung S6 Edge allows a non-privileged app toperform a factory reset without a permission or user con-firmation. Through exploiting another inconsistency onSamsung Note 2, an attacker can forge SMS messageswithout the SEND_SMS permission. Moreover, an in-consistency related to permission to Linux GID mappingallows apps to access the camera device driver with a nor-mal protection level permission. We have filed securityreports about the confirmed vulnerabilities to the corre-sponding vendors. We strongly believe that vendors, whohave source code and know more about their systems,can find more attacks from our detected risky inconsis-tencies. We also envision that in the future, vendors canuse our proposed tool and database to improve their cus-tomization process.

    Contributions. The scientific contributions of this pa-per are summarized as the followings: We have systematically identified possible security

    features that may hold different configurations be-cause of the Android customization process.

    We have developed five differential analysis algo-rithms and conducted a large-scale analysis on 591Android OS images. Our results produce significantinsights on the dangers of vendor customization.

    We have identified risky configuration inconsisten-cies that may have been introduced unintentionallyduring customization. Our results can help vendorssecurity analysts to conduct further investigation toconfirm whether the risks of the inconsistencies areoffset in the system or not. We have confirmed viaour own attacks that some inconsistencies can in-deed lead to actual s