“This one matters,” said the SANS Institute in its briefing on the Heartbleed OpenSSL security flaw last week.
As far as security incidents go, this one was a doozy: Not only did it impact on the majority of secure web sites across the internet, clients were later found to be just as vulnerable.
The encouraging aspect to this issue is that the patching and re-issuing of SSL certificates was swift from many sites, and a good thing too, as any server that used any of the affected versions of OpenSSL should be assumed to have had its memory dumped for the two years that this bug avoided detection.
On the flip side though, it is absolutely damning that an almost two-year, three-releases old Jelly Bean version of Android has been found to be vulnerable to Heartbleed.
Of all the mobile operating systems that could have been impacted, fate decided to choose the one that upgrades between major versions at a pace that makes glacial an overstatement.
Despite the fragmentation between differing versions of Android, it just happens that the impacted 4.1.x series of Jelly Bean is the version with the largest userbase by some stretch.
In statistics published by Google at the start of the month, of Android devices that are accessing Google’s Play Store, 5.3 percent of users are on the most recent KitKat release, 8.9 percent are on Jelly Bean 4.3, 18.1 percent use Jelly Bean 4.2, and 34.4 percent use the impacted Jelly Bean 4.1 series that was first released in mid-2012.
Given that 4.1 has been superseded for well over a year, and many flagship devices have been upgraded beyond that point, any devices left on Jelly Bean 4.1.1 or 4.1.0 are likely to remain stuck on it for quite some time.
With Google not releasing breakdown stats on the percentage of Android devices using 4.1.1 and 4.1.0, the best to hope for at this point is that most of the 34.4 percent are marooned on the unaffected 4.1.2 version.
The Heartbleed scenario does raise the question of the speed of patching and upgrading on Android. Take for instance, the example of the Samsung Galaxy S4, released this time last year, it has taken nine months from the July 2013 release of Jelly Bean 4.3 for devices on Australia’s Vodafone network to receive the update, it took a week for Nexus devices to receive the update.
Google’s patch for 4.1.1 is now making its way through the handset makers and telco companies that act as gatekeepers to Android updates, it will be a test for how rapid the architecture of the Android ecosystem can respond.
As someone that has suffered, and continues to do so, from a lack of expediency on Android updates, I’m far from confident that patching Heartbleed will be a swift and painless process.
Should this issue have impacted any of Android’s competitors — iOS, Windows Phone, Firefox OS, BlackBerry — the companies behind those operating systems would have been able to unilaterally push out that update for millions of users.
Google has taken steps to improve its ability to update and abstract additional user functionality into a core suite of Google apps, rather than adding it into Android itself, but it can only do so much.
When an issue arises with a core library built into an operating system, the only way to resolve it is to push out a core update.
Once again, the reason for Android’s popularity with telcos and handset makers, the ability to deploy customised versions of the operating system to promote one’s services and offerings, becomes it’s Achilles heel.
Heartbleed is asking plenty of questions of developers. Regulation has been proposed for cryptographic code, the low level of funding for struggling projects that are core to many open source operating systems has been highlighted, and why crucial security libraries continue to be written in ways and languages where issues like Heartbleed can occur.
Here we are, with the rest of the computing world patching OpenSSL and re-issuing secure certificates, and Android’s fix is caught somewhere in the abyss between OS maker, handset manufacturer, and telco.
From an Android perspective, it was lucky that Heartbleed did not impact the version of Android used by any Samsung flagship phones, or even Android 4.1.2. Stakeholders in Android need to inform consumers on what would happen if a major security issue in the kernel were to impact a widely-used Android release.
As it stands, the experience with the 4.1.1 patch has been less than great. Google is up to speed, it’s everyone else involved that is dragging the chain. Should handset manufacturers and telcos continue to be less than expedient, Google needs to develop a way to unilaterally protect its users — and while it may seem drastic, it would merely put Google on par with its competitors.
A bullet was dodged by Android this time, the next time a similar incident happens, it might not be so lucky.
ZDNet’s Monday Morning Opener is our opening salvo for the week in tech. As a global site, this editorial publishes on Monday at 8am AEST in Sydney, Australia, which is 6pm Eastern Time on Sunday in the US. It is written by a member of ZDNet’s global editorial board, which is comprised of our lead editors across Asia, Australia, Europe, and the US.
Previously on Monday Morning Opener
- Mapping out the next half a century of computing
- The end of Windows XP is also the end of everything we thought we knew about computing
- Microsoft’s Build powwow: Our wish list
- The Internet tsunami: 8 big insights on what it disrupts next
- Tablets: Not mobile enough or productive enough for many professionals
- Wanted: A Flipboard approach for the enterprise
- Smartphone innovation is dead: Here are four ways to breathe life into it again
Â
Article source: http://www.zdnet.com/heartboned-why-google-needs-to-reclaim-android-updates-7000028331/