Source-linked AI summary
Automatically Securing Permission-Based Software by Reducing the Attack Surface: An Application to Android
Alexandre Bartel, Jacques Klein, Martin Monperrus, Yves Le Traon
TL;DR
Permission-based software can grant applications more permissions than they need, leaving permission gaps that malware may exploit. The paper uses static analysis to infer required permissions and compute gaps, implementing the approach for Android. Evaluations found permission gaps in substantial subsets of two application datasets, while the approach depends on platform-specific permission knowledge and does not cover low-level checks through framework analysis alone.
Problem
Permission-based software can grant applications unused permissions, which malware may leverage to access additional resources.
Method
The paper uses static analysis, boolean matrix algebra, and platform-specific permission maps to infer required permissions and compute permission gaps.
Results
94/742 and 124/679 analyzed Android applications declared permissions they did not use, while the implementation identified 9562 framework entry points that check permissions.
Takeaways & Limitations
Automatically identifying unused permissions provides a way to reduce the attack surface of permission-based software and support systematic framework documentation.
Takeaways & Limitations
Framework-only analysis cannot detect permissions checked at the operating-system level, and the paper describes ongoing work to analyze native code with bytecode.
Abstract
from arXiv · showhide
A common security architecture, called the permission-based security model (used e.g. in Android and Blackberry), entails intrinsic risks. For instance, applications can be granted more permissions than they actually need, what we call a "permission gap". Malware can leverage the unused permissions for achieving their malicious goals, for instance using code injection. In this paper, we present an approach to detecting permission gaps using static analysis. Our prototype implementation in the context of Android shows that the static analysis must take into account a significant amount of platform-specific knowledge. Using our tool on two datasets of Android applications, we found out that a non negligible part of applications suffers from permission gaps, i.e. does not use all the permissions they declare.
1. INTRODUCTION
Permission-based security models assign applications permissions to access resources, but manual declarations can exceed actual needs. The paper proposes static analysis to identify and fix these permission gaps, reducing an application's attack surface.
- Permission-based models associate applications with permissions that users accept at installation and that are checked when resources are requested.
- Unused declared permissions create a permission gap that malware can exploit through techniques such as code injection or return-oriented programming.
- Reducing permission gaps reduces the resources available to an attacker who compromises an application, thereby reducing its attack surface.
- Permission gaps arise because framework and application developers manually document and declare required permissions, making the process error-prone.
- The paper proposes a generic approach using boolean matrix algebra and static analysis to approximate required permissions and compute permission gaps.
- The approach is implemented and evaluated on Android applications, with 94+35 applications reported as suffering from permission gaps.
2. THE PERMISSION GAP PROBLEM
Permission gaps occur when applications declare permissions they do not use, creating unnecessary attack surface. A study of Android applications and a broader evaluation both found such gaps in practice.
- Permission gaps occur because applications may declare permissions without using them, potentially exposing additional resources after compromise.
- Removing an unused CAMERA declaration would have prevented the described compromised application from accessing the camera after a buffer-overflow exploit.
- The study examined more than 1000 Android applications by approximating permission-requiring framework methods and checking application bytecode usage.
- 7/82 applications declared CAMERA without using it, while 3/35 declared but did not use RECORD_AUDIO.
- The study confirms that declared permission lists are not always required and motivates automated inference of required permissions.
3. ANALYZING PERMISSIONS
The paper formalizes permission-based software and uses static analysis to infer the permissions an application requires. Boolean vectors and matrices connect reachable framework entry points to protected permissions, enabling permission-gap computation.
- Definitions: Permission-based software has core platform, middleware, and application layers, with applications explicitly declaring permissions for middleware-mediated resource access.The framework provides the application API and checks whether applications have the required permissions.
- Definitions: A required permission protects a resource the application uses at least once, while a declared permission is listed in its manifest.The permission attack surface is minimal when required and declared permission sets are equal.
- Definitions: Static analysis infers permissions by approximating the required set, whereas testing can under-approximate it by missing unexecuted permission checks.The paper seeks to minimize the difference between inferred and required permissions while replacing manual manifest construction.
- A Calculus for Permissions: The access vector records reachable framework entry points, and the permission matrix maps those entry points to permissions they protect.Matrix rows represent entry points, columns represent permissions, and true cells denote protected-resource access.
- A Calculus for Permissions: Boolean matrix multiplication of the access vector and permission matrix yields the inferred permission vector for the application.A permission is inferred when its output cell is true.
- Extraction and Gap Computation: The framework matrix is built by checking which entry-point call graphs reach permission-enforcement points, then recording the associated permissions.This condenses call-graph reachability into a matrix of entry points by high-level permissions.
4. OVERVIEW OF ANDROID
Android applications use layered system components and services to access protected resources, while permissions are declared in the manifest and approved as a whole during installation. Permission enforcement occurs through system services and the Binder communication mechanism, and the framework can be modeled by mappings from entry points to permissions.
- Android consists of a modified Linux kernel, native libraries, Dalvik, a Java framework, and basic applications.
- Applications package Java bytecode, data, and a manifest in an .apk file, with developers declaring usable permissions in that manifest.
- Android applications comprise Activities, background Services, BroadcastReceivers for intents, and ContentProviders for storing and sharing data.
- System services let applications access potentially protected resources and enforce the associated permission checks through the system server.
- Binder mediates synchronous calls to remote services, which perform computations while system services enforce permission policy.
- At installation, users approve all declared permissions together; approved permissions are mapped to an application-specific UID and relevant Unix group memberships.
- Android 2.2 declares 107 high-level permissions, including permissions enforced at the framework level and eight also indirectly enforced at the kernel level.
- The Android system fits a generic framework model in which a matrix maps framework entry points to permissions, enabling inference of applications’ required rather than declared permissions.
5. STATIC ANALYSIS FOR ANDROID
The Android implementation detects permission gaps with static-analysis tools that map framework methods to permissions and extract methods used by applications. Its analysis depends especially on modeling Android’s service and Binder mechanisms and on constructing call graphs with Soot Spark.
- COPES uses a mapper to extract a binary framework-method-to-permission matrix and a sniffer to extract framework methods used by application code.
- Both COPES tools use static analysis, whose implementation required substantially more platform-specific handling than expected.
- The analysis specifically handles Android service and Binder mechanisms to support replication and adaptation to other permission-based platforms.
- COPES builds and manipulates call graphs using Soot’s Spark analysis together with Android service-mapping information.
- Spark is configured as context-insensitive, path-insensitive, flow-insensitive, and field-sensitive, combining broad path coverage with initialization-based edge reduction.
- Because Android’s API has no main entry point, COPES creates one artificial entry point per public framework class, with an all-public-method alternative that is less scalable.
5.2 Extracting Permission Enforcement Points
The analysis identifies permission-enforcement points but must recover the specific permissions checked when those values are supplied dynamically. It therefore supplements call-graph detection with intra-method and call-stack string analysis.
- Basic analysis detects that a permission check occurs but cannot determine the precise permission when the value is supplied dynamically.The permission may be passed as a String or an array of strings.
- A Soot String-analysis plugin recovers permissions passed directly, through variables, or through arrays using backward intra-method analysis.
- When the permission String is assigned indirectly, the analysis examines methods in the PEP method’s call stack.
5.3 Handling Binder-based Communication
Binder-based service calls require platform-specific information because static analysis cannot resolve their dynamic targets directly. COPES redirects proxy calls using the boot-time service lookup table and accounts for service identity changes.
- Static analysis cannot resolve service calls made dynamically through the binder without additional platform-specific information.
- COPES intercepts the boot-time service lookup table and uses it to redirect proxy calls to concrete service implementations.
- Field-sensitive or context-sensitive analyses require explicit service initialization so remote calls are included during call-graph construction.COPES supplies Spark with a special initialization class containing service objects.
- Permission checks executed under a service identity are discarded when computing an application’s gap, using flow-sensitive analysis around clearIdentity() and restoreIdentity().
5.5 Reflection in the Framework
Reflection and dynamic class loading can make framework call graphs incomplete, so the authors manually inspect the relevant Android classes. Their inspection finds no missed permission-enforcement points in the examined cases.
- Reflection makes call-graph construction incomplete by construction, requiring manual inspection of reflective framework classes.
- The framework’s reflective classes were manually analyzed, and the identified uses were unrelated to system-resource permission checks.Five classes were debugging classes; other reflective uses handled animations or testing.
- Dynamic class loading can make static analysis impossible because loaded classes are known only at runtime.
- Manual inspection of eight classes using loadClass found no missed permission-enforcement points because checks occurred before loading or the classes were unrelated to permission checks.
- The implementation uses Soot for framework analysis and ASM for application bytecode because end-user commercial applications may lack source code.
5.8 Recapitulation
The implementation exposed technical issues that may recur on other permission-based platforms and matter for reproducing the reported results.
- The authors expect the implementation problems to arise on other permission-based platforms and consider their solutions useful for future work.
- The authors identify these technical details as crucial for replicating their results.
6. EVALUATION
The evaluation finds that the static-analysis approach produces permission maps comparable to testing, while detecting permission gaps in applications from two Android markets. Static analysis also reveals platform-specific checks that testing can miss, but may over-approximate by analyzing irrelevant code.
- The analysis considers 71 high-level permissions and claims soundness at the Android framework level.
- 9,562 framework methods require at least one permission, with a median of 2 permissions checked per method.The maximum is 50 permissions, concentrated in a few context-dependent outliers.
- 82.3% of commonly analyzed methods have the same inferred permission set as Felt et al.’s testing approach, while no method loses a permission.Static analysis assigns one additional permission to 118 methods and two additional permissions to one method.
- Static analysis and testing are complementary: testing under-approximates permission checks, whereas static analysis over-approximates them.Static analysis can include irrelevant or dead code, while testing can miss specific usage scenarios.
- 94 of 742 analyzed applications in the alternative market and 124 of 679 in the official market declare permissions they do not use.Applications using reflection or class loading were discarded for soundness: 587 from the alternative-market dataset and 1,378 from the official-market dataset.
- Permission gaps are usually small: one unnecessary permission affects 76.6% of affected alternative-market applications and 64.5% of affected official-market applications.The remaining affected applications have larger attack surfaces of two, three, or more permissions.
7. RELATED WORK
The paper situates its contribution among static permission analyses, Android security studies, and empirical work on permission systems. Its distinction is an operational Android approach that accounts for platform-specific mechanisms such as Binder.
- Related work includes static analyses for Java permission lists and analyses identifying code that should be privileged.
- Android-specific Binder behavior prevents off-the-shelf Java static-analysis tools from resolving remote service calls.The paper’s approach therefore adapts static analysis to Android’s platform mechanisms.
- The paper differs from studies of social engineering, collusion, privacy leaks, privilege escalation, and permission-use patterns by targeting permission-gap reduction.
- Unlike primarily empirical studies of user reactions or permission-model effectiveness, this work proposes an operational software-engineering approach for Android and permission-based software.
8. CONCLUSIONS AND PERSPECTIVES
The paper presents a generic static-analysis approach for reducing the attack surface of permission-based software and implements it for Android. It reports broad framework coverage while identifying platform complexity as an ongoing boundary.
- The approach addresses the risks of excessive permissions by using static analysis to mitigate permission gaps.
- The Android prototype automatically identifies 9,562 framework entry points that check permissions.
- The current approach abstracts over low-level platform characteristics, motivating future analysis of native code and bytecode together.
- The authors are exploring permission enforcement as a cross-cutting concern that can add or remove enforcement points according to a security specification.