ScopeVerif: Analyzing the Security of Android’s Scoped Storage via Differential Analysis

ScopeVerif: Analyzing the Security of Android’s Scoped Storage via Differential Analysis

Speakers: Zeyu Lei

Conference: NDSS Symposium

YouTube: https://www.youtube.com/watch?v=drOtBSMA4q8

Overview

This talk introduces ScopeVerif, a novel dynamic analysis framework designed to rigorously evaluate the security, correctness, and consistency of Android's Scoped Storage model. Presented by Zeyu Lei, this research addresses critical concerns surrounding the implementation of Scoped Storage, a fundamental security redesign introduced in Android 10 to enhance user privacy and data isolation. The talk highlights how the inherent complexity and fragmentation of the Android ecosystem lead to vulnerabilities and inconsistent security enforcement across different Android versions and device manufacturers (OEMs).

ScopeVerif employs a sophisticated differential analysis approach, comparing expected security behaviors against actual system responses to uncover subtle deviations that signify security flaws. The significance of this work lies in its ability to systematically identify previously unknown vulnerabilities, reveal inconsistencies in how Scoped Storage rules are applied, and provide a robust methodology for future-proofing Android's file access control model against regressions and OEM-specific issues. The findings underscore the continuous challenges in maintaining a secure and consistent platform amidst rapid development cycles and diverse hardware integrations.

The research presented by Lei is particularly pertinent for Android developers, security researchers, and device manufacturers. It provides actionable insights into common pitfalls in implementing complex security features and demonstrates a powerful technique for automated vulnerability discovery. By identifying critical issues like metadata leaks and OEM-specific bypasses, ScopeVerif contributes significantly to improving the overall security posture of the Android platform, ultimately safeguarding user data from unauthorized access and manipulation.

Background

▶ Watch: Introduction to Android's Scoped Storage and its purpose. (0:00)

Prior to Android 10, the platform's file access control model was notoriously coarse-grained, particularly concerning external storage. Apps granted the READ_EXTERNAL_STORAGE or WRITE_EXTERNAL_STORAGE permission by the user could essentially access any file on external storage, including those belonging to other applications. This was likened to a "mail room situation," where once an individual gained access to the room, they could theoretically pick up any package, not just their own. This broad access posed significant privacy and security risks, as a single malicious or compromised app could potentially exfiltrate sensitive data from other applications.

Recognizing these limitations, Google introduced a major architectural overhaul with Android 10, known as Scoped Storage. The primary objective was to transform the "mail room" into a "locker room situation," where applications are confined to their own private storage directories and specific, well-defined shared directories. Under Scoped Storage, an app should only have access to its own app-specific folders, and other apps, even with user-granted permissions, should be explicitly denied access to these private areas. This model aims to enhance app sandboxing, limit data exposure, and provide users with clearer control over their data.

However, the implementation of Scoped Storage is fraught with challenges. Android's storage architecture is inherently complex, involving multiple APIs for file operations (some background, some requiring user interaction), diverse file types, and varying expected behaviors. The codebase is large and fragmented, with security logic often distributed across different components and layers, leading to potential duplication and inconsistencies. Furthermore, the rapid iteration of Android versions (12, 13, 14, etc.) introduces subtle, sometimes undocumented, changes to the storage access control model. Compounding this fragmentation is the prevalence of OEM customizations, where device manufacturers modify the Android Open Source Project (AOSP) to differentiate their products, potentially introducing new vulnerabilities or failing to integrate crucial security patches.

One well-known issue highlighting these challenges is the SAF loophole, which allowed attackers to partially bypass Scoped Storage and gain unauthorized access to files in other apps' private folders. This specific vulnerability served as a catalyst for the research, prompting a broader inquiry into the fundamental correctness, consistency, and effectiveness of Scoped Storage across the fragmented Android ecosystem. The motivation behind ScopeVerif was to move beyond isolated bug fixes and develop a systematic approach to answer fundamental questions: How correct is Scoped Storage in enforcing its rules? How consistent are its implementations across versions and devices? And how effective is it in preventing security and privacy issues comprehensively?

Key Findings

▶ Watch: Three key technical challenges in verifying Scoped Storage security. (3:00)

ScopeVerif proved highly effective in uncovering critical security and privacy issues within Android's Scoped Storage implementation. The research led to the discovery of 10 distinct issues, with a remarkable 9 of these being previously unknown vulnerabilities. These findings were not isolated incidents but rather symptomatic of deeper systemic problems, revealing significant inconsistencies in how Scoped Storage rules are applied across different Android versions and various OEM builds.

A notable achievement of ScopeVerif was its efficiency in vulnerability discovery, identifying a previously unknown issue within a single day of operation. All discovered findings were responsibly disclosed to both Google and Huawei, the respective platform and device manufacturers, leading to their acknowledgment and the issuance of bug bounties to the researchers. This validation from industry giants underscores the severity and impact of the identified vulnerabilities.

Two prominent case studies emerged from the research, illustrating the types of issues ScopeVerif is capable of detecting:

1. Metadata Leak: This critical privacy vulnerability demonstrated how an attacker could determine the existence of a file within another app's private folder without any permissions. By exploiting differences in error messages returned by the File API, ScopeVerif showed that "permission denied" indicated a file's existence, while "no such file or directory" confirmed its absence. This subtle information leak enables persistent cross-app user identification, posing a significant privacy risk.

1. SAF Loophole Huawei Version: This finding highlighted an OEM-specific security regression. ScopeVerif discovered that on Huawei's Android 14 builds, a specific usage of the Storage Access Framework (SAF) API allowed attackers to create or overwrite files in other apps' private directories. Crucially, this issue was a known vulnerability that Google had previously patched in earlier versions of AOSP. However, for "some unknown reasons," Huawei's customized build had failed to incorporate this essential security fix, demonstrating a critical gap in patch management and consistency across the Android ecosystem.

These findings collectively emphasize the necessity of continuous, systematic security validation for complex systems like Android, especially given its fragmented nature and the constant evolution of its security models.

Technical Deep Dive

▶ Watch: ScopeVerif's dynamic analysis approach and security rule extraction. (4:40)

ScopeVerif's core methodology is rooted in dynamic analysis combined with differential analysis, a powerful approach designed to systematically verify the correctness and consistency of Scoped Storage implementations. The general procedure involves three main steps: extracting security rules from documentation, generating comprehensive test cases for each rule, and then executing these tests to identify violations.

The first crucial step is translating natural language security rules, often found in Android's official documentation, into formalized, actionable security properties. For instance, a rule like "apps should not have access to other apps' private files" is categorized as a confidentiality rule. Other rules might fall under integrity (e.g., preventing unauthorized modification) or availability (e.g., ensuring legitimate access is not denied). Each rule is then associated with various file actions, such as reading, writing, moving, removing, or renaming files, as the rule should ideally hold true regardless of the specific operation.

The innovative aspect of ScopeVerif lies in its application of differential analysis to detect violations. This technique involves constructing a baseline representing the expected behavior if a security property holds true, and then comparing it against the actual execution results of a test case. Any significant difference between the baseline and the actual result indicates a potential violation.

For confidentiality rules, the goal is to prevent unauthorized information leakage, particularly about the existence or content of files. ScopeVerif constructs a baseline by simulating "perfect secrecy." This is achieved by attempting to access a file that is known not to exist in the target location. The feedback received (e.g., an "IOException" with "no such file or directory") serves as the baseline for a non-existent file. When testing a potentially existing file in another app's private folder, ScopeVerif observes the actual exception message. If the message differs from the baseline (e.g., "SecurityException" with "Permission denied"), it implies that the existence of the file has been leaked, even if its content remains protected. This subtle distinction in error messages allows ScopeVerif to infer information that should remain confidential.

For integrity rules, the objective is to ensure that files cannot be modified, deleted, or overwritten without proper authorization. The baseline for integrity is established by reading the target file's state before any modification attempt. Then, ScopeVerif executes a test case where the testing app attempts to perform an unauthorized modification (e.g., delete, overwrite, or rename). After the attempt, the file's state is read again. If there is any difference between the pre-attempt baseline and the post-attempt state, it signifies an integrity violation, meaning the file was illicitly altered or removed.

For availability rules, the framework aims to confirm that legitimate file operations are always possible for authorized entities. To establish a baseline for availability, ScopeVerif leverages the capabilities of a root user. It asks the root user to perform the intended file operation and records the feedback, which is expected to indicate successful availability. Subsequently, the testing app, operating under the specific permissions being evaluated, attempts the same operation. If the testing app achieves the same capability as the root user for an operation that should be restricted, or if a legitimate operation is unexpectedly denied, it indicates an availability issue. This comparison against a privileged baseline effectively highlights cases where an app might gain unintended access or be unfairly denied legitimate access.

By systematically applying this differential analysis across a multitude of APIs, file operations, and security rules, ScopeVerif provides a comprehensive and scalable approach to auditing the complex and fragmented landscape of Android's file access control, identifying both explicit security bypasses and subtle information leaks.

Demo / Proof of Concept

▶ Watch: Summary of ScopeVerif's findings: 10 issues, inconsistencies, rapid detection. (8:00)

While the talk did not feature a live, step-by-step demonstration of ScopeVerif in action, the speaker presented two compelling case studies that serve as concrete proofs of concept for the framework's capabilities in identifying real-world vulnerabilities. These examples clearly illustrate how ScopeVerif's differential analysis approach translates into discovering significant security and privacy flaws.

The first case study detailed the Metadata Leak, a privacy vulnerability uncovered by ScopeVerif. This issue revolves around the File API and its error handling. When an app attempts to read a file in another app's private folder, the system returns different error messages depending on whether the file exists or not. If the file exists but the app lacks permission, the error message would typically be "permission denied." However, if the file does not exist, the error message would be "no such file or directory." ScopeVerif leveraged this subtle distinction: by comparing these error messages, an attacker could reliably determine the existence of a file without needing any permissions. This proof of concept demonstrates that even seemingly innocuous error messages can leak sensitive metadata about the file system, enabling attackers to perform persistent cross-app user identification. The speaker emphasized that the exact technical details for performing this attack are described in their paper, encouraging attendees to read it for a deeper understanding.

The second proof of concept focused on the SAF Loophole Huawei Version, highlighting an OEM-specific security flaw. ScopeVerif discovered that on Huawei's Android 14 builds, a particular usage pattern of the Storage Access Framework (SAF) API allowed an attacker to create or overwrite files directly within another app's private directories. This was a critical integrity and confidentiality bypass. The speaker pointed out the significant detail that Google had previously identified and patched this exact vulnerability in earlier versions of AOSP. However, for reasons not elucidated in the talk, Huawei's customized Android 14 build had not incorporated this crucial security fix. This case study serves as a stark proof of concept for ScopeVerif's ability to detect inconsistencies and regressions introduced by OEM customizations, showcasing its value in ensuring security across the highly fragmented Android device landscape. Both examples underscore the effectiveness of differential analysis in pinpointing security vulnerabilities that arise from complex interactions, subtle implementation details, and inconsistencies across different Android environments.

Defensive Implications

▶ Watch: Case study: Identifying a metadata leak via File API. (8:15)

The findings from ScopeVerif carry significant implications for various stakeholders within the Android ecosystem, guiding defensive strategies against the identified classes of vulnerabilities.

For Android platform developers (e.g., Google), the research highlights the critical need for more robust and centralized security logic for core features like Scoped Storage. The fragmentation of security checks across different components and layers, coupled with potential duplication and subtle undocumented behaviors, creates fertile ground for bugs. Google should consider implementing more stringent, automated validation tools similar to ScopeVerif in their continuous integration pipelines to catch regressions and inconsistencies early. Furthermore, clearer documentation of API behaviors, especially regarding error messages and exceptions, is paramount to prevent information leaks like the metadata vulnerability.

For Android device manufacturers (OEMs), the "SAF Loophole Huawei Version" serves as a stark warning. OEMs must prioritize the timely and complete integration of security patches released by Google. Customizations, while important for differentiation, must not come at the expense of security. OEMs should adopt rigorous testing methodologies, potentially leveraging tools like ScopeVerif, to ensure their customized Android builds maintain the same or higher security posture as the stock AOSP. This includes comprehensive testing across all supported Android versions and device models to identify any OEM-specific regressions or newly introduced vulnerabilities. The observation that "whatever happens in other Google's Android it also happens on the Harmony OS" (a Huawei-developed OS, though the speaker clarifies it's Huawei's Android build) suggests a shared vulnerability landscape, emphasizing the need for robust internal security reviews.

For application developers, the metadata leak is a crucial lesson. It demonstrates that relying solely on permission checks is insufficient; subtle side channels, such as distinguishing between "permission denied" and "no such file or directory" error messages, can expose sensitive information. Developers should be mindful of the information leaked by their apps' error messages and consider generic error responses where specific details could compromise privacy. When interacting with external storage, developers should strictly adhere to the documented Scoped Storage APIs and avoid undocumented behaviors that might seem to work but could be exploited or break in future updates.

Finally, for the broader security research community, ScopeVerif provides a powerful framework and methodology. The success of differential analysis in uncovering subtle, previously unknown issues demonstrates its potential applicability to other complex, fragmented software systems. Researchers can adapt and extend ScopeVerif's techniques to analyze other critical Android security features or even other operating systems, driving further advancements in automated vulnerability discovery and platform security. The interaction during the Q&A, where the speaker clarified that some violations were "intended behaviors" or "undocumented features" rather than bugs, underscores the importance of close collaboration between researchers and developers to accurately classify findings and ensure effective remediation.

Key Takeaways

• Scoped Storage Complexity Leads to Vulnerabilities: Despite being a major security redesign, Android's Scoped Storage model suffers from inherent complexity, fragmentation, and inconsistent implementation across versions and OEMs, leading to critical security and privacy issues.
• Differential Analysis is a Powerful Discovery Technique: ScopeVerif's novel use of dynamic differential analysis, comparing expected security behaviors against actual system responses, is highly effective in uncovering subtle, previously unknown vulnerabilities, including information leaks and access bypasses.
• Error Messages Can Leak Sensitive Metadata: The "Metadata Leak" demonstrated that seemingly innocuous differences in API error messages (e.g., "permission denied" vs. "no such file or directory") can be exploited to reveal confidential information, such as the existence of files in other apps' private storage, without requiring any permissions.
• OEM Customizations Introduce Security Inconsistencies: The "SAF Loophole Huawei Version" highlighted that OEM customizations and delays in integrating security patches can reintroduce previously fixed vulnerabilities, creating a fragmented and inconsistent security landscape across the Android ecosystem.
• Continuous, Automated Validation is Crucial: The success of ScopeVerif underscores the critical need for comprehensive and automated security validation tools to proactively identify and mitigate vulnerabilities arising from rapid platform evolution, diverse implementations, and complex interactions within large software systems.
• Collaboration Clarifies "Bugs" vs. "Features": The research process revealed that some "violations" might be intended but undocumented behaviors, emphasizing the importance of communication between security researchers and platform developers to correctly classify findings and drive appropriate actions.

About the Speaker(s)

Zeyu Lei is a researcher who presented the work on ScopeVerif at the NDSS Symposium. Based on the Q&A session, it was noted that Zeyu Lei is currently on the job market. The research demonstrates a strong background in systems security, dynamic analysis, and Android platform security.