50 Shades of Support: A Device-Centric Analysis of Android Security Updates

50 Shades of Support: A Device-Centric Analysis of Android Security Updates

Speakers: Abbas Acar

Conference: NDSS Symposium

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

Overview

Android, the world's most popular mobile operating system with over three billion active devices, faces a persistent challenge in delivering timely and consistent security updates to its vast user base. This talk, "50 Shades of Support: A Device-Centric Analysis of Android Security Updates," presented by Abbas Acar at the NDSS Symposium, delves into the intricate and often irregular landscape of Android security update distribution. While the Android Open Source Project (AOSP) has introduced measures like Security Patch Levels (SPLs) to improve traceability, the actual rollout to end-users remains fraught with delays and inconsistencies. Previous research, often limited to flagship devices or short timeframes, has painted an incomplete picture, largely attributing issues to fragmentation.

This research distinguishes itself by adopting a comprehensive device-centric approach, analyzing the complete lifecycle of an average Android device and scrutinizing the security update practices of Original Equipment Manufacturers (OEMs). The scale of the problem is immense: Samsung alone supports a billion users across 1,400 unique models, 97 countries, and 109 carriers, necessitating the creation, customization, and testing of approximately 20,000 variations for each security update. This colossal workload inevitably leads to irregularities, including delays or complete failures in update delivery for specific models or regions, a frustration frequently voiced by users in online forums.

The study addresses four critical questions to bridge this knowledge gap: characterizing the maintenance chronicle of Android devices, identifying factors impacting update distribution, quantifying the risks posed by unpatched devices, and pinpointing immediate user concerns alongside exemplary OEM practices. By analyzing a massive dataset of official security update records, this work provides an unprecedented, granular view into the real-world state of Android security update provision, offering crucial insights for users, developers, and policymakers alike.

Background

▶ Watch: Introduction, motivation, and research questions for Android updates (0:00)

The Android security update ecosystem is a complex multi-stakeholder process designed to protect users from vulnerabilities. Vulnerabilities can be discovered by various entities, including Google's internal teams, AOSP partners, or independent security researchers, each typically assigned a unique CVE identifier. The rollout process, illustrated in Figure 1 of the presentation, begins with AOSP publishing a monthly Android Security Bulletin (ASB). This bulletin details new vulnerabilities and their corresponding patches, encompassing issues across the Android system, kernel, chipset, and even OEM-specific components.

Following the ASB publication, OEMs are responsible for applying the relevant patches to their specific device models and setting the device's SPL, typically in a YYYY-MM-DD format. This process also involves applying OEM-specific customizations and conducting extensive compatibility tests to ensure stability and functionality. For devices branded by mobile carriers, an additional approval step by the carrier is required before the update can be released. In contrast, OEM-branded devices receive updates directly from the OEM. Pixel devices, manufactured by Google, notably bypass the OEM optimization and carrier approval stages, significantly reducing potential delays. Finally, the end-user installs the update via an over-the-air (OTA) mechanism. An important exception to this traditional model is Project Mainline, introduced with Android 10, which enables AOSP to directly push security updates for modularized components via Google Play system services, bypassing the OEM and carrier pipeline for those specific modules.

Security updates are generally delivered through various methods and types of SPLs. Partial SPLs, typically ending with "-01" (e.g., YYYY-MM-01), primarily cover Android system components. Complete SPLs, ending with "-05" (e.g., YYYY-MM-05), offer a stronger security posture by covering both Android system components and closed-source components, such as those from Qualcomm chipsets. Beyond monthly security patches, Major OS Upgrades are published annually, incorporating significant security enhancements and patches for 100-200 CVEs, alongside generic OS updates. Google Play System Updates, facilitated by Project Mainline, address CVEs in specific modularized components and are published under the partial SPL.

OEMs exhibit varying approaches to announcing and delivering these updates. Oppo and Xiaomi often do not explicitly include the SPL in their historical announcements, necessitating the researchers to download and analyze firmware to extract this crucial information. Samsung, conversely, consistently includes the SPL in all its announcements. Google maintains a dedicated webpage where all firmware updates are published, allowing for direct matching of SPLs with specific build numbers. Furthermore, some OEMs, like Xiaomi and Google, publish End-of-Support (EOS) product lists, providing transparency regarding when devices will cease to receive updates. The research observed that Xiaomi, Oppo, and Samsung predominantly utilize partial SPLs, whereas Google consistently deploys complete SPLs, indicating a higher standard of comprehensive security coverage for its Pixel line.

Key Findings

▶ Watch: Understanding the Android security update ecosystem and process (2:00)

The comprehensive device-centric analysis presented in this talk unveiled critical insights into the real-world state of Android security updates, highlighting significant disparities and risks across the ecosystem. The study, leveraging a massive dataset of 367,000 official security updates for 599 unique devices from four major OEMs (Samsung, Xiaomi, Oppo, Google) across 97 countries and 109 carriers, established several key findings:

Firstly, there are significant variations in security update distribution across OEMs, regions, and even device models, often regardless of their officially designated support type (e.g., monthly, quarterly). Google consistently delivers monthly security updates throughout the guaranteed lifetime of its Pixel devices. In stark contrast, Samsung's update frequency and duration vary considerably based on the device's support type and age, while Oppo and Xiaomi generally offer fewer updates over shorter support durations.

Secondly, the research quantified the substantial and escalating risks posed by unpatched Android devices after they reach their End-of-Life (EOL). An unpatched device can accumulate 76 CVEs within the first three months post-EOL, escalating to 382 CVEs around two years and 600 CVEs within five years. Critically, 89% of these vulnerabilities are exploitable without user interaction, 86% require only medium or low attack complexity, and 27% are remotely exploitable over a network. These findings underscore that users of unsupported devices face immediate and significant threats from publicly known, easily exploitable vulnerabilities.

Thirdly, the study identified critical discrepancies between official OEM support declarations and actual update delivery. Devices sometimes remain on official support lists (e.g., monthly or quarterly) despite having ceased receiving updates long ago. Furthermore, partnership agreements like Android Enterprise Recommended (AER), which guarantee support dates, were found to have instances where certified devices had not received updates for extended periods, directly contradicting their certified status. Misleading announcements regarding extended support periods were also observed, where a substantial number of promised devices failed to receive updates within the stated timeframe.

Finally, the research highlighted exemplary practices that, if widely adopted, could significantly enhance transparency and user security. These include providing a guaranteed end-of-support date (as implemented by Motorola and Pixel), publishing a clear EOL device list (Motorola and Xiaomi), and offering model-specific support lists (Oppo), which provide more granular and accurate information than generic device categories. These practices offer a roadmap for OEMs to improve accountability and user trust in the security update process.

Technical Deep Dive

▶ Watch: Detailed device-centric dataset collection methodology (4:00)

The methodology employed in this research was fundamentally device-centric, aiming to characterize the full lifecycle of Android devices from a security update perspective. To achieve this, a large, representative dataset of official security updates was meticulously collected from public sources, spanning nearly a decade from 2014 to 2023. This dataset comprised 367,000 official security update records covering 599 unique devices from four major OEMs: Samsung, Xiaomi, Oppo, and Google, used across 97 countries and associated with 109 carriers.

Data Collection Specifics:

• Samsung: The team leveraged Samsung's dedicated webpage for security updates, which are published per model/CSC pair (e.g., SM-F926U1/TMB, where CSC denotes country or country-carrier). By constructing possible URLs from official model lists and community-compiled CSC lists, they queried almost half a million potential pairs. This yielded 21,461 unique pairs and 354,000 security updates from April 2015 to March 2023. Crucially, 343,000 of these records included an SPL value, along with the firmware build release date and Android version.
• Xiaomi: Data was collected using an official API and a third-party website that monitors updates every six hours since 2018. This provided 2,286 official security updates from December 2014 to June 2023. Xiaomi releases firmware for 10 regions (e.g., China, Global, EEA). Using device codenames, 223 unique devices were identified, resulting in 756 model-region pairs.
• Oppo: Data was gathered from regional software update websites by constructing country-device pairs. This resulted in 9,241 security updates for 72 devices across 35 countries. A significant challenge was that Oppo only includes the SPL in the changelog for the latest release. To overcome this, researchers downloaded all available firmware updates to extract SPLs from configuration files. Oppo does not specify carriers.
• Google: 900 full OTA images for 20 Pixel devices were obtained from Google's dedicated website (excluding older Nexus devices). The build date was used as the release date, and SPLs were extracted using a separate Google table. Google does not categorize updates by region but sometimes specifies the carrier.

In addition to update records, Support Lists from OEMs were collected (via Wayback Machine snapshots for Samsung, Oppo, and Xiaomi, and guaranteed dates for Google) to understand official expected support behavior. These lists categorize devices into monthly, quarterly, and biannual support periods.

Methodology for Update Efficiency Evaluation:

Four key metrics were used to evaluate update efficiency:

1. Update Count: The total number of security updates received.
2. Support Duration: The actual time span between the first and last security update.
3. Update Frequency: The average duration between consecutive security updates.
4. Release Delay: The time elapsed between the AOSP SPL release and the OEM firmware release.

Supported Period Analysis (RQ1, RQ2):

• Samsung: An average device received 16.5 security updates (2.5 major OS upgrades) over an average support duration of 757 days, with an average update frequency of 50 days. The average release delay was 140 days. Notably, SPL assignment behavior improved significantly after June 2018, with the majority of devices updated within 70 days, contrasting with earlier batch assignments after hundreds or thousands of days.
• Xiaomi: Devices received an average of 3 security updates over 170 days, with an average frequency of 48 days and an average release delay of 32 days, improving from 163 days in 2018 to 25 days in 2023.
• Oppo: Devices averaged 8 security updates over 583 days, with an average frequency of 85 days and a release delay of 35 days.
• Google: Pixel devices demonstrated the most stable support, consistently receiving monthly security updates without delay or missed SPLs, aligning perfectly with their published support lists.

Unsupported Period Risks (RQ3):

To quantify the risks of using devices after EOL, EOL was defined as the date of the device's last received security update. Researchers identified 4,579 CVEs impacting devices in the dataset by matching the device's last Android version and chipset against vulnerability databases (AOSP, Samsung, NIST). CVEs published before EOL were filtered out. A time-based risk analysis grouped CVEs received after EOL into 3-month quarters, using a cumulative weighted average to track their evolution.

• An unpatched device accumulates an average of 76 CVEs in the first quarter post-EOL, rising to 382 CVEs around two years, and 600 CVEs in five years.
• Critical CVEs (up to 50) tend to taper off after two years, while medium and high-severity CVEs continue to accumulate.
• Critically, 89% of these vulnerabilities can be exploited without user interaction.
• 86% can be exploited with medium or low complexity, with less than 1% requiring high complexity.
• The attack vector analysis showed 67% can be exploited locally, and 27% remotely through the network, with physical or adjacent network connections rarely required.

Evaluation of Impacting Factors (RQ2):

• Support Type (Samsung): A direct correlation was found between support type and update metrics. Monthly-supported devices averaged 33 updates, 1034 days support, 30 days frequency, and 25 days delay. Quarterly-supported devices received fewer updates (9), shorter duration (560 days), and longer delays (42 days). Biannual devices were even worse (4 updates, 442 days, 62 days delay).
• Geolocation (Samsung): Significant regional variances were observed. Top 5 monthly-supported regions (e.g., Luxembourg, Russia, Switzerland) received twice as many updates with three times shorter delays compared to bottom 5 regions (e.g., Honduras, Costa Rica, Paraguay).
• Device Type (Samsung): Smartphones stayed on support lists more than twice as long as tablets (2202 days vs. 927 days). Samsung tablets do not receive monthly support.
• Carrier Association: The influence of carriers on security update distribution was found to be minimal across all OEMs, with only slight differences observed for Samsung.
• Partnership Agreements (AER, Samsung Knox): These programs primarily influence the eligibility for a certain support type rather than significantly altering update quality within that support type. While AER-certified Samsung devices showed slightly better metrics, overall, discrepancies were still observed.

This detailed methodology and analysis provided the empirical foundation for the study's key findings, illustrating the deep complexities and inconsistencies within the Android security update ecosystem.

Demo / Proof of Concept

▶ Watch: Collecting OEM support lists for device lifecycle analysis (6:00)

While the talk did not feature a live technical demonstration or a traditional proof-of-concept exploit, the speakers presented compelling data and a specific case study to illustrate their findings regarding the risks of unpatched devices. This case study focused on the Samsung Galaxy Z Fold3 5G, a device officially on Samsung's monthly support list.

The researchers highlighted that four specific US carrier-branded pairs of the Galaxy Z Fold3 5G had not received security updates for almost 10 months. These particular devices were running Android 12 with a Qualcomm SM8350 chipset. Through their analysis, the team identified 142 impacting CVEs that had been published during this unpatched period, including six critical-severity vulnerabilities and 82 high-severity ones.

A particularly alarming finding was that all six critical CVEs identified were remotely exploitable and required no user interaction. As an example, CVE-2023-20946, a remote privilege escalation vulnerability in Bluetooth settings, was specifically cited. The critical implication was that patches for these vulnerabilities already existed in AOSP and had been released to other devices, yet they had not reached these specific Galaxy Z Fold3 5G end-users. This case study served as a concrete example of how real-world devices, even flagship models, can remain vulnerable to severe, easily exploitable threats due to inconsistencies in OEM and carrier update distribution, directly supporting the quantitative risk analysis presented in the "Unsupported Period Risks" section.

Defensive Implications

The findings of this research carry significant defensive implications for various stakeholders within the Android ecosystem, including OEMs, end-users, and enterprise organizations. Understanding these implications is crucial for mitigating the widespread security risks identified.

For Original Equipment Manufacturers (OEMs):

• Enhance Transparency and Consistency: OEMs must move beyond vague "support lists" and adopt more transparent practices. This includes providing guaranteed End-of-Support (EOL) dates for all devices, similar to Motorola and Google Pixel.
• Publish EOL Device Lists: Clearly communicating which devices have reached EOL and will no longer receive updates, as done by Motorola and Xiaomi, helps users make informed decisions.
• Implement Model-Specific Support Lists: Rather than generic device categories, providing support schedules based on specific models or even model-CSC pairs (as seen with Oppo's approach) offers more accurate and actionable information.
• Address Discrepancies: OEMs need to actively monitor and rectify discrepancies between their official support lists, partnership agreements (like AER certifications), and actual update delivery. Devices on support lists or certified under programs must genuinely receive timely updates.
• Improve Announcement Accuracy: Misleading announcements about extended support periods that do not materialize erode user trust and leave devices vulnerable. OEMs should ensure their public commitments align with their actual update performance.
• Prioritize Critical Patches: The study shows that critical, remotely exploitable CVEs accumulate immediately post-EOL. OEMs must ensure that even devices nearing EOL or those experiencing delays receive critical security patches as a priority.

For End-Users:

• Be Aware of EOL: Users should actively seek out and understand the guaranteed support duration for their Android devices at the time of purchase. This information should be a significant factor in their buying decision.
• Understand Risks of Unpatched Devices: It is crucial for users to recognize that devices no longer receiving security updates become increasingly vulnerable to critical, often remotely exploitable, and low-complexity attacks. The illusion of safety simply because a device "still works" is dangerous.
• Verify Update Delivery: Being on an OEM's support list does not guarantee regular updates. Users should regularly check their device's current Security Patch Level (SPL) and compare it against the latest AOSP ASB.
• Consider Custom ROMs (with caution): For devices that have reached EOL but are still functional, users technically proficient enough might consider community-supported custom ROMs (e.g., LineageOS) as a potential, albeit unofficial, way to receive extended security updates. This path, however, comes with its own set of risks and complexities.

For Enterprises and Organizations:

• Scrutinize AER Certification: While Android Enterprise Recommended (AER) devices offer certain guarantees, organizations should not solely rely on the certification. The study found discrepancies where AER-certified devices still lagged in updates. Enterprises must verify the actual update performance of devices being deployed.
• Implement Device Lifecycle Management: Establish clear policies for device replacement based on actual security update reception rather than solely on official EOL dates.
• Prioritize Devices with Consistent Support: When procuring devices, prioritize OEMs and models that have a proven track record of timely and consistent security update delivery, like Google Pixel devices.
• Network Segmentation: For legacy Android devices that cannot be immediately replaced, employ network segmentation and other compensating controls to limit their exposure to potential threats, especially if they are known to be unpatched against remote vulnerabilities.

In essence, the defensive implications underscore the need for greater transparency and accountability from OEMs, and increased vigilance and informed decision-making from end-users and enterprises, to collectively enhance the security posture of the vast Android ecosystem.

Key Takeaways

• Significant Update Disparities: Android security update distribution varies drastically across OEMs, geographic regions, and even specific device models, indicating a fragmented and inconsistent ecosystem.
• Escalating Risks Post-EOL: Unpatched Android devices face immediate and rapidly accumulating risks from critical, remotely exploitable vulnerabilities that require minimal attacker effort and no user interaction, particularly shortly after their End-of-Life (EOL).
• Support Lists Are Not Guarantees: Inclusion on an OEM's official "support list" (monthly, quarterly, biannual) does not guarantee timely or consistent security updates; significant discrepancies between stated policy and actual delivery are common.
• Geolocation and Device Type Matter: For some OEMs like Samsung, geographical location and device type (e.g., smartphones vs. tablets) significantly impact the timeliness, frequency, and duration of security update delivery.
• OEM Transparency is Key: OEMs should adopt exemplary practices such as providing guaranteed EOL dates, publishing clear EOL device lists, and offering model-specific support schedules to enhance transparency, accountability, and user security.
• Minimal Carrier Influence: While carriers play a role in the update chain, their influence on the overall security update distribution metrics was found to be minimal across the analyzed OEMs.

About the Speaker(s)

Abbas Acar presented this comprehensive work titled "50 Shades of Support: A Device-Centric Analysis of Android Security Updates" at the NDSS Symposium. The transcript indicates his role as the lead presenter of this detailed research into Android security update practices.