This week, our security team headed to Las Vegas for BlackHat
—the largest technical security conference in the world. On Thursday, August 4th
, Lookout’s security team presented “Don't Hate the Player, Hate the Game: Inside the Android Security Patch Lifecycle.” We asked: If a new Android vulnerability is discovered today, when will the phone in your pocket be patched?
Our team studied firmware update events across millions of Android devices around the world to answer this question (and many more).
Much like PC operating systems (e.g. Windows or Mac OS), flaws in mobile operating systems are regularly identified and need to be fixed. The PC patch process is significantly less complex than mobile: software vendors can push online updates directly to licensed users on a regular schedule. On mobile, however, mobile patches involve multiple stages and players, including OS vendors, device manufacturers, carriers, as well as end users. Because of this complexity, it takes a long time to patch mobile devices, leaving them exposed to potential attacks that could exploit these known vulnerabilities until the entire ecosystem is caught up.
Why some people want vulnerabilities
In the past, malware including jSMSHider
exploited known vulnerabilities to gain privileges on the device that they could not have accessed otherwise.
Many mobile devices do not offer users full control over their device hardware or operating system. To gain complete control, people will “root” or “jailbreak” their device. The process of rooting or jailbreaking takes advantage of operating system vulnerabilities to bypass security protections on a device.
This conflict of interest between vulnerability disclosure and the ability for people to fully control their own device poses a great security issue.
Software vendors want to fix vulnerabilities as quickly as possible, before they can be exploited and used maliciously, so well-intentioned researchers typically disclose vulnerabilities they find to the software vendor. On mobile devices, however, there is a conflict of interest. Because vulnerabilities are often the only way to root or jailbreak devices, many researchers do not want vulnerabilities to get fixed so they can maintain full control over their devices. The desire to gain full control over devices creates a disincentive for researchers to disclosure vulnerabilities. Until this conflict of interest is solved, there will likely continue to be vulnerabilities publicly released without devices being fixed into the future.
The Patch Process
Google has developed an extremely fast response to push updates and fix security flaws on the Android OS—often within days or weeks of discovery. Google’s CTS
(compatibility test suite) has helped drive critical updates and keep phones up-to-date. The CTS is a test suite every OEM must test against in order to be considered Android Compatible. Often patches to critical vulnerabilities are included in past releases of Android (e.g. Froyo, Gingerbread) and as part of the CTS. In this case, the CTS tests act as a forcing function to make sure OEMs include critical fixes in any firmware versions they ship. Once the fixes are pushed into the Android Open Source Project (AOSP
) repository by Google, manufacturers and carriers can roll out these updates to their users quickly; however, due to the wide range of customizations on devices, device manufacturers must pull from the AOSP repository, merge in any of their customizations, and produce a new firmware update for each device. This stage of the patching process is the most complex, as a single device model may have hundreds of variations of an update to support carrier-specific customizations.
If we look across some of the key vulnerabilities that have occurred on Android, we see that the time it takes for a device to reach its vulnerability half-life (the time it takes from a public announcement of the vulnerability to having 50% of devices in market patched) varies significantly. While the Exploid exploit took 42 weeks to reach its half life, CVE-2010-1807 (WebKit NaN) was patched on 50% of devices in 30 weeks. There are a handful of vulnerabilities that have yet to reach their half-life, for example RageAgainstTheCage has gone 40 weeks and counting, and 55% of devices remain vulnerable as of July 2011.
Factors that affect the length of patch cycles include:
- Time it takes Google to release the patch to the Android Open Source Project repository.
- The level of commitment by OEM manufacturers and carriers to update devices with the latest release.
- The number of customizations on devices and time it takes to flash each firmware build with the updated OS release.
While great strides have been made in patching vulnerable devices, we see opportunities to continue to improve the patching cycle.
- Manufacturers should take advantage of the Compatibility Test Suites to cherry pick fixes for their builds.
- The industry should continue to build tools to track and manage patch levels (particularly in the enterprise).
- Carriers and OEMs should make security a first class-feature in releases, ensuring that the latest patches are always included.
- Players in the ecosystem should agree to unlock bootloaders, thus eliminating the conflict of interest between vulnerability disclosure and the ability for users to control their own devices.
While the patch cycles for mobile operating systems are typically longer than that of the PC, there are signs that it is getting better. Android CTS has proven to help drive adoption of critical updates. For example, several prominent devices shipped in the last few months have been shipped with critical security fixes. Until everyone in the mobile ecosystem considers security a top priority by accelerating patch cycles and removing the conflict of interest for vulnerability disclosure, longer patch cycles, and thus vulnerable devices, will continue to persist. We're hopeful that mobile device patching will continue to improve and eventually even improve on the PC status quo.