Google Refuses To Patch The
Jelly Bean WebView Vulnerability
Following the news that Google has refused to patch the Jelly Bean WebView vulnerability, Mark Kraynak, CPO at Imperva and Rob Miller, Senior Security Consultant for MWR InfoSecurity explain how this huge workload has been shifted from Google to the device manufacturers.
Mark Kraynak, CPO at Imperva explains:
It’s a bit ironic that Google would make the claim that patching is too hard when in the last few weeks Google released major vulnerabilities in Apple and Microsoft products despite those vendors saying much the same thing about those vulnerabilities and asking for more time to patch, to which Google responded that 90 days is too long to let vulnerabilities lie. The underlying problem here is that sometimes it is too hard to patch quickly and oftentimes, security patches introduce new problems into the underlying software. Beyond the squabbles of internet giants, it really proves the point that external solutions for attack protection and virtual patching, like web application firewalls, can take the time pressure off the patching process and should be an integral component of application protection.
Rob Miller, Senior Security Consultant for MWR InfoSecurity:
Google’s decision to only provide WebView updates in more recent devices brings it in line with the policies of many other major organizations, as maintaining support for every version of a product is an expensive undertaking. Unfortunately given Android’s unique lifecycle and the spread of versions still in use, the change will affect many end users, app developers and handset manufacturers.
Google’s decision to support only Android versions 4.4 and above according to Google’s Adrian Ludvig was made because making the huge number of required updates was ‘no longer practical to do safely’. This means that huge workload has been shifted from Google to the device manufacturers. In 2013, HTC responded to complaints that it did not keep its Android devices up to date by releasing a diagram showing just how many steps were required between receiving changes in code to releasing a version for its users. This latest statement from Google means that this process is likely to be even longer, increasing the time that users must use handsets with known security vulnerabilities. It is foreseeable that the manufacturers may choose to stop supporting older handsets, as the workload now required of them is simply unaffordable.
The other victim of this latest change in policy will be the app developers. Many developers build their apps to rely at least in part on WebViews. With nearly a billion Android users’ devices now likely running WebViews known to be vulnerable, developers will need to make difficult choices as to whether they should include their own webkit libraries, risk having their users connect to their servers in an insecure manner or whether they should restrict access to around 60% of their user base. If an attacker could compromise the app’s servers, a single webkit exploit would compromise every outdated device that then connected to it.
By making this change, Google has unburdened itself of difficult and expensive work, but it will be device manufacturers and Android app developers that will need to pick it up if they want their users to remain safe online. Users themselves should follow Ludvig’s advice and make sure that they download the latest browsers for their Android phones, such as Chrome or Firefox, and hope that the manufacturers and developers are willing to pick up the slack from Google.
