Ariadne: Navigating through the Labyrinth of Data-Driven Customization Inconsistencies in Android

Parjanya Vyas

34th USENIX Security Symposium (USENIX Security '25) · Day 2 · System Security 3: Mobile Platforms

Overview

The Android ecosystem, characterized by its open-source nature, allows device manufacturers (OEMs) to extensively customize the core operating system (OS) to differentiate their products. While this data-driven customization fosters innovation and unique user experiences, it inadvertently introduces a complex challenge: access control inconsistencies. These inconsistencies arise when OEM-specific modifications to the Android Framework, particularly those interacting with shared global state variables, fail to implement appropriate security checks, leading to potential vulnerabilities. The talk introduces Ariadne, a novel static analysis and graph theory-based tool designed to systematically identify these elusive access control flaws within customized Android ROMs.

Watch on YouTube · Slides

Visual summary for Ariadne: Navigating through the Labyrinth of Data-Driven Customization Inconsistencies in Android by Parjanya Vyas
Visual summary for Ariadne: Navigating through the Labyrinth of Data-Driven Customization Inconsistencies in Android by Parjanya Vyas

Key moments

  1. 0:00 Introducing Ariadne and data-driven inconsistencies
  2. 2:00 Inconsistencies from Java object membership relations
  3. 4:00 Overview of key challenges in analysis
  4. 5:00 ZTE example: why precise data flow is crucial
  5. 8:00 Challenge: Ambiguous access control implications
  6. 9:00 Challenge: APIs with varying operation granularity
  7. 10:00 Ariadne's solution: static analysis and dependency graphs

Ariadne: Navigating through the Labyrinth of Data-Driven Customization Inconsistencies in Android

Speakers: Parjanya Vyas

Conference: USENIX Security

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

Overview

The Android ecosystem, characterized by its open-source nature, allows device manufacturers (OEMs) to extensively customize the core operating system (OS) to differentiate their products. While this data-driven customization fosters innovation and unique user experiences, it inadvertently introduces a complex challenge: access control inconsistencies. These inconsistencies arise when OEM-specific modifications to the Android Framework, particularly those interacting with shared global state variables, fail to implement appropriate security checks, leading to potential vulnerabilities. The talk introduces Ariadne, a novel static analysis and graph theory-based tool designed to systematically identify these elusive access control flaws within customized Android ROMs.

Presented by Parjanya Vyas at USENIX Security, Ariadne addresses a critical gap in existing Android security analysis tools. Traditional approaches often struggle with the intricate interdependencies introduced by data holders—global state variables that maintain critical system information—and the diverse ways APIs interact with them. Ariadne's strength lies in its ability to precisely model these relationships and infer the "expected" access controls, thereby flagging deviations as inconsistencies. The research demonstrates Ariadne's efficacy by uncovering numerous real-world vulnerabilities across various OEM ROMs, highlighting the urgent need for more rigorous security validation in the Android customization pipeline.

The significance of Ariadne extends beyond merely identifying bugs; it provides a systematic methodology for understanding and mitigating a class of vulnerabilities inherent to the Android customization model. By offering a scalable and precise analysis, Ariadne empowers both researchers and developers to better secure the fragmented Android landscape. Its findings underscore that even seemingly minor API additions or modifications can have profound security implications if not carefully crafted with consistent access control policies, especially when operating on shared system resources.

Background

▶ Watch: Introducing Ariadne and data-driven inconsistencies (0:00)

The problem of access control inconsistencies in Android ROMs stems from the inherent flexibility of the Android Open Source Project (AOSP), which permits extensive modifications by device manufacturers. These customizations often involve adding new APIs or altering existing ones, many of which interact with data holders—global framework variables that store critical system state. The core issue arises when different APIs operating on the same or related data holders, or even different granularities of the same data, are protected by inconsistent or insufficient access control policies.

Consider a simple example from a Xiaomi ROM presented in the talk: two APIs, getExtensions and hasExtensions. Both operate on a global framework variable mExtensions. While hasExtensions, which merely checks for the existence of a key, enforces a system-level access control, getExtensions, a getter API that could potentially expose the same information, enforces no access control at all. This is counterintuitive; if an existence check requires a permission, a direct getter revealing the data should at least be as strictly protected. This scenario exemplifies a clear inconsistency that could lead to information disclosure. Another illustrative case involves Java object semantics: if a specific field's getter requires protection, the getter for the entire parent object containing that field should ideally be at least as protected, due to their membership relation.

However, identifying these inconsistencies is fraught with challenges:

  1. Precise Data Flow Analysis: Accurately tracing how data flows through the Android framework requires highly field-sensitive and object-sensitive data flow analysis. Without this precision, a tool can quickly generate false positives. An example from a ZTE ROM demonstrates this: setAlarmAlignType and setLockScreenCleanType both operate on mSettingsMap within different instances of BaseOptimizerController. A naive analysis might flag an inconsistency if one enforces access control and the other doesn't, but in reality, they operate on distinct memory copies, making different access controls perfectly valid.
  2. Computational Expense and Scope: Precise data flow analysis is computationally intensive. Applying it broadly to an entire Android ROM is unfeasible. Therefore, defining a very precise and selective analysis scope is critical for scalability.
  3. Diverse Data Types: Data holders come in arbitrary structures and types, including complex collections like ArrayLists or HashMaps. The relationships and operations on these diverse structures must be accurately modeled to infer correct access control implications.
  4. Inherent Ambiguity and Uncertainty: Many access control implications are not deterministic. For instance, while a protected field getter implies the parent class getter should also be protected, the reverse is not always true: a protected parent class getter doesn't necessarily mean every child member needs the same protection, but at least one might. This uncertainty must be quantified.
  5. Varying Semantics and Granularity: The operations performed on data holders can vary significantly in their semantics and granularity. An API might not be a simple getter but might iterate over a collection, filter values, and return only a subset (e.g., getDeviceOnlyUserRestrictions in a Xiaomi ROM). Modeling these nuanced operations is essential for accurate inference.

These challenges highlight the complexity of ensuring consistent access control in a highly customized, data-driven environment like Android ROMs, laying the groundwork for Ariadne's novel approach.

Key Findings

▶ Watch: Overview of key challenges in analysis (4:00)

Ariadne's evaluation across a diverse set of Android ROMs yielded significant and impactful findings, demonstrating its effectiveness in uncovering a previously under-addressed class of security vulnerabilities.

Firstly, the tool proved to be highly accurate. When applied to AOSP ROMs, where the baseline for secure access control is assumed to be perfect (in line with prior research), Ariadne achieved approximately 97% accuracy. This high precision indicates a low rate of false positives, which is crucial for a security analysis tool designed to assist developers and security researchers. The ability to accurately distinguish between legitimate differences and actual inconsistencies is a testament to Ariadne's sophisticated modeling of data flow and access control implications.

Beyond its accuracy, Ariadne's primary contribution lies in its ability to discover novel vulnerabilities in real-world customized Android environments. The tool was evaluated on 13 different ROMs spanning eight distinct vendors (including prominent names like Samsung and Xiaomi) and covering Android versions 8 through 14. Across this extensive dataset, Ariadne identified a total of 90 unique access control inconsistencies. These findings represent critical security flaws that could potentially be exploited by malicious applications.

To further validate the severity and exploitability of these identified inconsistencies, the researchers successfully built 13 proof-of-concept (PoC) exploits. The fact that most of these PoCs received an acknowledgment from the respective vendors underscores the genuine impact and practical relevance of Ariadne's discoveries. These vulnerabilities could range from unauthorized information disclosure to privilege escalation, depending on the nature of the exposed data holder and the API's operation.

A crucial aspect of Ariadne's utility is its complementary nature to existing security analysis tools. The talk explicitly states that Ariadne is not a "one-stop solution" but rather fills a specific gap left by prior works. When compared to other established tools like BO or AC minor, Ariadne was able to identify 30 new inconsistencies that these tools missed. This demonstrates that Ariadne's unique methodology, particularly its focus on data-driven customization and granular modeling of data holder interactions, allows it to uncover vulnerabilities that fall outside the scope of other analysis techniques, thus providing a more comprehensive security coverage when used in conjunction with them.

In summary, Ariadne's key findings highlight its precision, its capability to uncover numerous unique and exploitable access control flaws in real-world Android ROMs, and its ability to significantly enhance the overall security posture of the Android ecosystem by complementing existing security analysis toolchains.

Technical Deep Dive

▶ Watch: ZTE example: why precise data flow is crucial (5:00)

Ariadne's architecture is meticulously designed to overcome the challenges of precise data flow analysis, diverse data types, and inherent ambiguities in access control implications within customized Android ROMs. It operates in two main phases: Static Analysis and Graph Creation, followed by Inference and Inconsistency Identification.

Phase 1: Static Analysis and Graph Creation

The first phase involves a deep static analysis of the decompiled Android ROM to construct abstract models known as Access Control Dependency Graphs (ACDGs).

  1. Target Variable Selection: To address the computational expense and define a precise analysis scope, Ariadne employs a selective approach to target variables. It excludes variables that are unlikely to contribute to data-driven flaws, such as local variables, variables inaccessible to apps, and non-self-contained variables. This intelligent filtering ensures that the computationally intensive precise data flow analysis is focused only on relevant global state holders.
  1. Access Control Dependency Graphs (ACDGs):
  • Nodes: The fundamental components of an ACDG are nodes representing framework variables, which are the data holders, and their members (e.g., fields within an object). To model the varying granularity of operations (e.g., an API acting on some or all members of a collection), Ariadne introduces synthetic members: all and some. These synthetic nodes explicitly represent whether an operation targets the entire collection or a filtered subset.
  • Edges: The connections between nodes are edges, which represent access control implications. These implications arise from two primary sources:
  • Operations on Data Holders: The specific actions (getters, setters, existence checks, filtered operations) performed by APIs on data holders.
  • Relations Between Data Holders: Structural relationships like a member to its containing class, a class to its specific field, a specific type to a generic type, or sibling relations between related data holders.
  • Crucially, most of these relations are uncertain in nature, a factor that Ariadne explicitly quantifies and accounts for during the inference phase.
  1. ACDG Construction Example (Xiaomi ROM):

The talk illustrates ACDG construction with a Xiaomi code snippet involving mExtensions, an ArrayList of UserRestrictions.

  • Ariadne first identifies mExtensions as a data holder, creating a node for it.
  • Recognizing mExtensions as an ArrayList of UserRestrictions, it adds a node for UserRestriction (representing the collection's member type) and an "contains member" edge.
  • For an API like getUserRestrictions that acts as a getter on all members of the UserRestriction collection, Ariadne creates the synthetic node all and connects it to the UserRestriction node.
  • If another API operates on some members, a some synthetic node is created and linked.
  • Finally, if UserRestriction itself contains primitive field members, nodes for these fields are added, establishing class-to-member relations. This detailed modeling captures the complex structure and operational nuances of data holders.
  1. Access Control Annotations: During graph construction, Ariadne also analyzes the APIs themselves to extract any explicitly enforced access controls (e.g., android.permission.READ_PHONE_STATE). These permissions are then added as access control annotations to the relevant nodes in the ACDG.

Phase 2: Inference and Inconsistency Identification

With the annotated ACDF in place, Ariadne moves to inferring missing access controls and identifying inconsistencies.

  1. Quantifying Uncertainty with Reduction Factors: To handle the inherent ambiguity of access control implications, Ariadne assigns reduction factors to each edge in the ACDG. These factors quantify the uncertainty associated with propagating an access control implication across a particular relation. For example, if two ACDF nodes are siblings, the uncertainty that an access control on one should apply to the other might be 30%, leading to a 70% reduction factor (meaning only 70% of the "relevance weight" is propagated). The exact values of these factors are determined through manual analysis and experimentation, but their relative differences are what matter most.
  1. Access Control Propagation (Selective Flooding): Ariadne employs a technique akin to taint tracking, but instead of sensitive data, it propagates access control annotations.
  • Propagation starts with a high relevance weight (e.g., 0.95 or 0.99) assigned to initial access control annotations.
  • As an access control propagates through the ACDG via its edges, its relevance weight is multiplied by the reduction factor of each traversed edge. This systematically reduces the confidence in the propagated access control based on the uncertainty of the underlying relation.
  • The process uses selective flooding, ensuring that propagation occurs in a defined direction (e.g., from member to container, or specific to generic) to avoid back-propagation and circular dependencies.
  • This mechanism allows Ariadne to quantify the confidence level of an inferred access control at any given node.
  1. Final Annotations and Inconsistency Detection:
  • After propagation, each data holder node in the ACDG will have a ranked list of inferred access control annotations, ordered by their accumulated relevance weights.
  • Ariadne then directly propagates these inferred access controls to the APIs that operate on these data holders.
  • Finally, it compares these inferred access controls with the actual access controls explicitly present in the system for those APIs.
  • If an inferred access control is stricter than the actual access control enforced by an API, Ariadne flags this as a potential inconsistency. This indicates that the API is under-protected given its operations on the data holder and its relations.

This sophisticated two-phase approach, grounded in precise graph modeling and uncertainty quantification, allows Ariadne to accurately pinpoint subtle yet critical access control flaws that are often overlooked by less granular analysis techniques.

Demo / Proof of Concept

▶ Watch: Challenge: APIs with varying operation granularity (9:00)

While the talk transcript does not include a live demonstration of Ariadne in action, the researchers successfully validated their findings by building 13 proof-of-concept (PoC) exploits based on the inconsistencies identified by Ariadne. The fact that "most of which we actually received an acknowledgment" from the respective vendors is a strong testament to the practical exploitability and severity of the discovered vulnerabilities. This rigorous validation process confirms that Ariadne's theoretical framework translates directly into the identification of actionable security flaws in real-world Android ROMs. These PoCs would likely have demonstrated how a malicious application could bypass intended access controls to read sensitive data or perform unauthorized operations due to the inconsistent permissions.

Defensive Implications

▶ Watch: Ariadne's solution: static analysis and dependency graphs (10:00)

Ariadne's findings offer crucial insights for various stakeholders involved in the Android ecosystem, particularly for improving the security posture of customized ROMs.

  1. For Android ROM Developers and OEMs:
  • Integrate Ariadne into CI/CD: OEMs should integrate tools like Ariadne into their continuous integration and delivery pipelines. Running such a static analysis tool before releasing new ROM versions or updates can proactively identify and remediate access control inconsistencies.
  • Adopt Stricter-by-Default Policies: When introducing new APIs or customizing existing ones that interact with data holders, developers should err on the side of caution and apply the strictest necessary access controls. It's easier to relax permissions later than to fix exploitable vulnerabilities post-release.
  • Consider Granularity of Operations: Developers must be acutely aware of how APIs operate on data holders, especially collections. An API that filters or returns a subset of a collection might still expose sensitive information if its inferred access control is not met. The all and some synthetic nodes in Ariadne's model highlight this critical distinction.
  • Comprehensive Review of Data Holder Interactions: Special attention should be paid to global state variables (data holders) and any new API that reads from or writes to them. A thorough security review should consider not only the direct operation but also the implications of relationships between data holders.
  1. For Security Researchers and Auditors:
  • Complementary Tooling: Ariadne is designed to cover a specific gap. Security professionals should leverage it alongside other established tools like BO or AC minor for a more comprehensive and holistic assessment of Android ROM security. This multi-faceted approach ensures broader coverage of potential access control flaws.
  • Focus on Customization Layers: The research underscores that the customization layer, often overlooked in generic Android security analyses, is a fertile ground for vulnerabilities. Future research and audits should specifically target these OEM-specific modifications.
  1. For the Android Ecosystem as a Whole:
  • Raise Awareness: The findings should raise awareness within the Android development community about the subtle yet significant security risks introduced by data-driven customization. Education on secure coding practices for customized Android frameworks is vital.
  • Standardize Best Practices: Encouraging the development and adoption of best practices for access control definition in customized Android components can help mitigate these issues at a systemic level.

By understanding and acting upon the insights provided by Ariadne, the Android ecosystem can move towards a more secure and consistently protected environment, even amidst the diversity of OEM customizations.

Key Takeaways

  • Data-Driven Customization Risks: Android ROM customizations, while beneficial for feature differentiation, frequently introduce subtle access control inconsistencies due to varied API interactions with shared global data holders.
  • Ariadne's Novel Approach: Ariadne is a static analysis and graph theory-based tool that precisely models these data holder relationships and operations to infer missing or insufficient access controls.
  • Addressing Key Challenges: The tool overcomes challenges like the need for precise field-sensitive and object-sensitive data flow analysis, the computational expense of broad analysis, diverse data types, inherent ambiguity in implications, and varying operational granularities.
  • Effective Vulnerability Discovery: Ariadne successfully identified 90 unique inconsistencies across 13 ROMs from 8 vendors (Android 8-14), leading to 13 acknowledged proof-of-concept exploits. It also found 30 new inconsistencies missed by prior tools, demonstrating its unique contribution.
  • Technical Foundations: Its core technical innovation lies in the creation of Access Control Dependency Graphs (ACDGs) with synthetic members to model granularity, and the use of reduction factors and selective flooding with relevance weights to propagate and quantify inferred access controls.
  • Call to Action for Developers: ROM developers should integrate such analysis tools into their development workflows, adopt stricter-by-default access control policies, and meticulously consider the full security implications of API operations on data holders and their relationships.

About the Speaker(s)

Parjanya Vyas is a researcher associated with the SSG research group. The presentation highlights his expertise in static analysis and Android security, particularly in uncovering complex access control vulnerabilities within customized Android ROMs.

Reviews

Dr. Zero (Offensive Security Researcher) — STRONG ACCEPT

Solid systems-security research with a clear novel contribution: modeling access control implications through data-holder relationship graphs rather than just API-level permission checks. Finds real bugs across real shipping ROMs, builds PoCs, gets vendor acks — the work is done, not just proposed.

Heather Calloway (CISO) — WEAK

Ariadne is credible security research with real findings — 90 inconsistencies, 13 acknowledged PoCs, coverage across major OEMs. But this talk is built for researchers, not for the people who govern the risk it exposes. The gap between the technical result and any operational or institutional response is never closed.

→ Top-rated talks at 34th USENIX Security Symposium (USENIX Security '25)

All talks from 34th USENIX Security Symposium (USENIX Security '25)