CVE-2017-8850 in OxygenOS
Summary
by MITRE
An issue was discovered on OnePlus One, X, 2, 3, and 3T devices. Due to a lenient updater-script in the OnePlus OTA images, and the fact that both ROMs use the same OTA verification keys, attackers can install HydrogenOS over OxygenOS and vice versa, even on locked bootloaders, which allows for exploitation of vulnerabilities patched on one image but not on the other, in addition to expansion of the attack surface. This vulnerability can be exploited by Man-in-the-Middle (MiTM) attackers targeting the update process. This is possible because the update transaction does not occur over TLS (CVE-2016-10370). In addition, physical attackers can reboot the phone into recovery, and then use 'adb sideload' to push the OTA (on OnePlus 3/3T 'Secure Start-up' must be off).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/25/2020
This vulnerability represents a critical flaw in OnePlus device firmware update mechanisms that fundamentally undermines the security boundaries between different operating system variants. The issue stems from a poorly configured updater-script within the OnePlus OTA images that fails to enforce proper verification constraints between different ROM versions. The vulnerability affects a wide range of OnePlus devices including the OnePlus One, X, 2, 3, and 3T models, creating a widespread security concern across multiple generations of hardware. The root cause lies in the shared OTA verification keys used across different ROMs, which eliminates the cryptographic separation that should exist between OxygenOS and HydrogenOS installations. This design flaw creates a scenario where attackers can bypass normal security restrictions that would typically prevent installation of incompatible firmware versions, effectively allowing arbitrary code execution through the update process.
The technical exploitation of this vulnerability occurs through multiple attack vectors that leverage the lack of proper TLS encryption during the update transaction. The absence of TLS encryption in the update process, as referenced in CVE-2016-10370, creates a window of opportunity for Man-in-the-Middle attackers to intercept and modify firmware updates in transit. This weakness in the transport layer security allows attackers to perform malicious updates without detection, as the system accepts OTA packages regardless of their origin or intended target OS variant. The vulnerability operates at the system level through the Android bootloader and recovery environment, where the updater-script fails to validate the target system state against the source firmware package. This creates a direct path for privilege escalation and system compromise that bypasses traditional security controls.
The operational impact of this vulnerability extends far beyond simple firmware modification, as it allows attackers to exploit patches that exist in one OS variant but not in another. This creates a sophisticated attack surface where vulnerabilities that have been addressed in one firmware version can be re-introduced through malicious updates to the alternative OS variant. Physical attackers can exploit this weakness by rebooting devices into recovery mode and using adb sideload functionality to push modified OTA packages directly to the device. This attack vector is particularly dangerous because it requires minimal technical expertise and can be executed without requiring specialized tools or significant physical access to the device. The vulnerability effectively nullifies the security benefits of having different OS variants with distinct patch levels, creating a scenario where attackers can select the most vulnerable version of the firmware to target.
The security implications align with CWE-284, which addresses inadequate access control in software systems, and follows the attack patterns outlined in the MITRE ATT&CK framework under the T1059.001 technique for command and scripting interpreter. The vulnerability demonstrates a classic case of insufficient input validation and weak cryptographic enforcement in the update process, creating persistent security risks that can be exploited by attackers with varying levels of technical expertise. Organizations and users should implement immediate mitigations including disabling automatic updates, using secure network connections when updating, and considering physical security measures to prevent unauthorized access to device recovery modes. The vulnerability also highlights the importance of proper key management and the need for unique verification mechanisms between different software variants in embedded systems, as outlined in industry best practices for secure firmware update processes.