In August 2010, hackers bent on jailbreaking Android smartphones found a vulnerability in the way the Android debugger handled an overwhelming number of processes. The code designed to exploit the flaw, dubbed RageAgainstTheCage, allowed users to reflash their smartphone and install custom firmware.
Google quickly patched the vulnerability in the Android Open Source Project, but there the fix languished. Smartphone manufacturers did not make pushing the patch out to users a priority. So, in March 2011, malicious programmers found an opportunity with the unpatched vulnerability. A Trojan horse dubbed DroidDream exploited the security issue to compromise more than 250,000 unpatched Android smartphones.
Nearly a year later, despite the threat of similar attacks, more than half of Android smartphones remain vulnerable to the flaw, according to mobile security firm Lookout.
The Android operating system's patch process poses a quandary for Google and a danger to users. Android's openness allows bugs to be found faster, but that benefit is offset by a longer supply chain in which manufacturers and vendors test patches at a glacial pace. Smartphone manufacturers must first create custom builds of the operating system that include their addon software, then they test the software. Next, carriers take the firmware update and test it to make sure it does not harm their networks.
The end result: Pushing patches out to users' smartphones is slowed.
"The fundamental problem is that there are too many cooks in the kitchen," says Timothy Vidas, a doctoral researcher at Carnegie Mellon University focusing on Android security.
Android: A reverse-engineer's dream
In a presentation on Android security at the Usenix Workshop on Offensive Technologies, Vidas and his colleagues pointed to patching delays as a major security issue for Android-based smartphones.
The Android 2.2 "Froyo" operating system, for example, was released in May 2010, fixing major vulnerabilities. Yet Motorola Mobility and HTC took seven months to issue an update for their smartphones. Samsung took even longer, releasing its software update nearly a year later, according to the CMU researchers.
For attackers the delays are a boon, because they can study the fixes and create exploits for the masses of unpatched devices. "Attacks stay viable for much longer, and a crafty user can actually reverse engineer some of the earlier patches to find the vulnerability and use that to exploit slower updating devices," says Daniel Votipka, a CMU researcher and co-author of the Android security report.
Other groups have highlighted the long patch cycle as well. In an analysis of the Android 2.6.32 kernel performed in November 2010, static analysis firm Coverity found 0.47 defect per line of code, better than the software industry as a whole.
Yet in chasing down the source of flaws, Coverity found that only a few ended with Google. Many others led to open source components and their developers, some of whom never responded to the company's bug reports. Were the issues fixed? The company does not know.
"It is an example of the complexity of the software supply chain, it has become more expansive because the amount of suppliers that people have for their software," says Andy Chou, the chief scientist at Coverity.
The worries come as attackers are already starting to focus more heavily on compromising mobile devices. IBM's X-Force security research lab estimates that 2011 will see twice as many exploits of vulnerabilities as the previous year. Lookout has seen malware take off from fewer than 100 attacks in 2010 to more than 400 so far this year.
Compared to the PC world, where tens of millions of attacks are detected each year, the numbers are small, but the trend is clear: Security researchers and attackers are increasingly targeting mobile devices, and most campaigns are focused on the Android operating system.
The patch problem is not unique to Android, but it is worse for Android
Although Android is the focus, perhaps due to its well known softness as a target and its growing market share, the problems with mobile patching is not just an issue for Google. Other mobile operating system makers also have to deal with the delay.
"Mobile operating systems, in general, have longer patch cycles given the number of different people involved," says Tim Wyatt, principal security engineer at Lookout.
Case in point: flaws in the WebKit HTML rendering engine, which powers most smartphone browsers. In July 2010, researchers reported a use-after-free vulnerability in WebKit. Google fixed the issue in the Chromium browser within eight weeks and ported the fixes to the stock Android source code soon after.
It took Apple until March 2011, eight months, to fix the issue on its iOS devices. And Android handset makers? Because the companies do not specify the vulnerabilities patched in their firmware updates, it remains a large question mark.
For Google, the patch issue is more acute because of its choices with security design and its open app marketplace. Apple's popular iPhone, for example, has additional defences that can make attacking it more difficult.
First, Apple vets every application posted to the App Store, complicating though not preventing the publishing of a malicious program. And the iOS platform has more security designed in, says Dino Dai Zovi, an independent security researcher and author of the "Mac Hacker's Handbook." He notes, "There is a tapestry of security defences on iOS that block you at every stage, which do not exist on Android."
Finally, compared to Google, Apple and BlackBerry maker Research in Motion have greater control over their devices. Thus, security flaws are fixed and distributed faster than the carrier-published Android patches.
Google needs to force a change to reduce the patch cycle
Users have no simple solution to fix the problem themselves. In the PC market, slow-to-patch software makers led to third party vulnerability management software to fill the gap, but the same has not occurred in the mobile security market.
One reason for the lack of a solution is the same reason that some smartphones are so secure, says Marc van Zadelhoff, worldwide director of security strategy for IBM: "They are not all equally accessible. There is less of a third party security ecosystem that can help on the mobile side, because it is less accessible to the patch management vendors."
Instead, much of the solution to the problem has to be spearheaded by Google and other operating system makers. Smartphone manufacturers and carriers have to revamp their patching processes to speed smaller, more agile updates, says CMU's Vidas.
Tools such as the Android Compatibility Test Suite (CTS) help smartphone manufacturers and carriers move along software updates and ensure that critical patches are included in the new firmware. Yet, updating frequently requires the whole firmware to be modified and replaced on a user's device.
By separating the different layers and components of the code, Google and the Open Handset Alliance could minimise the changes and reduce the quality testing required to sign off on an update, shortening the time, says Kevin Mahaffey, CTO at Lookout. "The solution is to move toward a more packaged-based update mechanism," he says. "Smaller updates means less QA and faster patching."
There is hope: The forthcoming Android 4 "Ice Cream Sandwich" release is expected to dramatically reduce the fragmentation among Android versions. The wide adoption of the newest operating system version could free up developers to push out patches and simplify updates.
At the technical level, the patching problem has been widely fixed on the user side. Just five years ago, when researchers found a serious vulnerability, patching the issue required the customer to visit a carrier's store, says Mahaffey. "Now we have over-the-air updates, which is great, even though there are still wrinkles on the back end that need to be ironed out."
Even Apple is jumping on the benefits of over-the-air updates, building the feature into iOS 5, which will be released on October 12, the last major operating system maker to do so. The move is a necessary security step, as the company found that about half of all iPhones brought into its Apple Stores had not been synced with a computer, the only way to get patches in iOS 4 and earlier.
With Google speeding up fixes for the Android source code and users getting automatic updates, the only remaining bumps in the process are the smartphone manufacturers and the carriers.
Until they get onboard, their users and subscribers will be left at risk. So far, they've shown little interest, so Google needs to step in and force the issue.