Android Browser Security—What You Haven't Been Told

This article focuses on flaws in Android's stock web libraries, while acknowledging related exploits. Some modern Android browsers have critically weak encryption and other dangerous flaws that cannot be patched or otherwise corrected. This weakness extends to multiple browsers and applications and is determined by the linkage to the system webcore on older OS versions. HTML applications that do not provide their own rendering engine should be avoided for all versions of Android less than 5.0.

Recent statistics indicate that 19% of the population accessing internet information systems have been the victims of an exploit or data breach, causing 45% to reduce or eliminate reliance upon electronic commerce and communication (www.theregister.co.uk/2016/05/13/americans_cutting_back_on_online_activity_over_security_and_privacy_fears). Computer security flaws are resulting in a direct impact on the economics of online business, and this must be corrected.

Most mobile platforms (including Android) owe a great debt to the KHTML rendering engine from the KDE Konqueror web browser. Mobile HTML is essentially a monoculture from the perspective of an OS default browser—they all emerge from KHTML, which won this position by providing a high-quality codebase under a reasonable license at the right time.

Although one would hesitate to call Apple a consistently good steward of KHTML due to past friction with the Konqueror project (https://blogs.kde.org/2005/04/29/bitter-failure-named-safari-and-khtml), the Safari browser introduced a compelling rework of KHTML known as WebKit. Apple has provided both new features and regular security fixes for WebKit (more than 100 security-related patches in 2015), which eventually were brought back to Konqueror (arstechnica.com/information-technology/2007/07/the-unforking-of-kdes-khtml-and-webkit). As Safari moved from desktop MacOS to mobile iOS, WebKit assumed the mantle of mobile browser leadership, and that role never has been seriously challenged.

Google also adopted WebKit into both Android and the Chrome web browser. Chrome has become the dominant browser by market share, and it receives regular updates from Google on all platforms where it is supported.

However, Google also added WebKit as a library to Android. Any application can link the system WebKit to render HTML as part of the User Interface (UI) by calling WebView, which links in /system/lib/libwebcore.so.

The problem with Android's bundled WebKit is that for older versions, it is never updated, which is not well known. Android 5.0 Lollipop is the first release where the bundled WebKit can be patched.

For Android 4.4 KitKat, the bundled WebKit 537.36 (jimbergman.net/webkit-version-in-android-version) and its TLS implementation does not conform to best-practice encryption as defined in RFC 7525 (https://www.rfc-editor.org/rfc/rfc7525.txt). As reported by the Qualys SSL Scanner (https://www.ssllabs.com):

These software flaws preclude the use of the KitKat system WebKit for sensitive transactions of any kind. Android JellyBean, which spans numerical releases of 4.1 through 4.3, has WebKit version 534.30, which is even worse, as it wasn't actually updated since Android version 4.0.1 Ice Cream Sandwich:

Google cannot and will not patch these or other bugs (www.zdnet.com/article/google-why-we-wont-patch-pre-kitkat-android-webview), because the Android patch process is both technically and politically (too) difficult—in Google's own words, patches are “no longer practical to do safely”. Google regularly abandons large segments of the Android base, and the above design flaws now infect more than 50% of Android devices. As of April 4, 2016, KitKat is 33.4% of the total Android base; Jelly Bean is 21.3%, and earlier versions sum to 4.9% (https://developer.android.com/about/dashboards/index.html). Web browsing of sensitive data on those platforms is unsafe if the system libraries are involved.

This problem is exacerbated by wireless carriers who still stock KitKat, Jelly Bean and earlier versions. Even the largest of carriers are guilty of this activity, and they include no disclosure that these older OS versions have weak, exploitable encryption and a slew of other flaws, which place them at a severe disadvantage for sensitive traffic. Some carriers spend far more effort in locking phones with bootloaders that require kernels bearing digital signatures than they have ever spent on security patches.

Original Equipment Manufacturers (OEMs) cause equal trouble. Although many “stock browsers” in various versions of Android use the system WebKit, some OEMs build separate versions of WebKit for their branded browsers that exhibit the same (lack of) support as shown by Google. OEM/vendor browsers also cannot be trusted with sensitive data.

The US Federal Communications and Trade Commissions (FCC and FTC) have announced a joint investigation into Google and its partners over the lack of security updates for Android (www.theregister.co.uk/2016/05/09/fcc_ftc_android_updates), which may result in future architecture changes but is unlikely to secure the older releases. Ideally, the FCC would compel carriers and OEMs to release signing keys for phones that have gone without security patches for more than six months, giving users of abandoned phones the option of third-party security support.

Had Microsoft taken the final Trident rendering engine from Windows XP's Internet Explorer and locked it to 50% of the Windows user community while actively preventing updates, the condemnation would have been fierce and brutal. The time has come to recognize that what Google has done is far worse—XP and KitKat support ended within a few months of one another, but Microsoft does not allow XP to proliferate through third parties as Google does with its orphaned products.

It was likely with some measure of relief that Apple and the WebKit team greeted the news that Google was forking the code, forming the BLINK engine and leaving the project (www.wired.com/2013/04/blink). Google has the worst security record of any large WebKit implementation. Although other Linux distributions also lag on WebKit security (https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates), none has the ubiquity of Android. Google's departure will only improve WebKit's security standing.

A number of browsers in the Google Play Store are reputedly faster and more feature-rich than Chrome. Some even assert greater security, which I soon will refute here. Chrome is generally seen as a conservative choice by app review sites, and it is rarely listed in first place in Android browser reviews.

These faster browsers often simply wrap new UI controls around the system WebKit, and thus inherit all of the security flaws of the Android version upon which they run.

Browsers that run with degraded security, as tested on Jelly Bean and reported by the Qualys SSL Scanner (https://www.ssllabs.com), include Apus, Apus Turbo, Best Browser, Boat Browser, Brave (Link Bubble), CM Browser, Dolphin, Dolphin Zero, Easy, Flynx, Flyperlink, Ghostery, Javelin, Maxthon, Mercury, Naked Browser, Next Browser, Ninesky, Safe Browser and UC Browser. These browsers are to be avoided on 4.4 KitKat and lower versions of Android. See Table 1 for details.

Surprisingly, JellyBean does include the latest TLSv1.2 encryption protocol, but it is disabled by default. There is a procedure to enable it that a developer must follow to secure an application with this feature (blog.dev-area.net/2015/08/13/android-4-1-enable-tls-1-1-and-tls-1-2). A few of the browsers mentioned above have done so, but many have not, either out of ignorance or sloth. There are extensive options for detailed cipher control (https://developer.android.com/reference/javax/net/ssl/SSLSocket.html) that can be used to pass more of the Qualys SSL Labs tests with the standard WebKit (by disabling SSLv3, RC4, export ciphers and so on), but none of the tested “rebadged-WebKit” browsers listed above have done so (likely as no best-practice details the procedures).

Beginning with Android 2.3 Gingerbread, Google made the surprising decision to alter the preferred cipher order, switching to RC4-MD5 from Android 2.2 Froyo's AES256-SHA1 (https://op-co.de/blog/posts/android_ssl_downgrade). Although it appears that this was done to mirror the Java standards, the impact is described as “a sign of horrible ignorance, security incompetence or a clever disguise for an NSA-influenced manipulation”. This flaw remained in place for the initial Android JellyBean 4.1 release, although it appears to have been corrected by release 4.3.

Moving onward to third parties, the CM Browser application specifically advertises that it is “Secure: Malicious & Fraud Protection” with the “#1 antivirus engine...which can protect you from malicious threats.” Despite these claims, its use of the WebKit system exposes it to all the problems of the older platforms. The Safe Browser advertises anti-spyware/-virus, but the SSL test results surely negate any dubious benefit from a malware host list. The Ghostery browser appears to be available as a plugin for Firefox—use it in this manner for better encryption support.

Opera Mini deserves special mention. In the default configuration, the Qualys SSL scanner detects the “Presto” rendering engine, not WebKit, and it passes all of the security tests. However, if the “data savings” setting is switched from “extreme” to “high”, then WebKit is detected (not Presto), and all of the tests fail. It appears that, while Presto is active, all of Opera Mini's browser traffic is routed through Opera's servers for pre-rendering and compression. This is deceptive, so Opera Mini's failing grade is reported here.

All of the browsers tested were free, but some have “ad-free/pro” versions that must be purchased. Be sure to test via the Qualys SSL scanner before paying for any Android browser to avoid purchasing a failure.

This problem does not end with browsers. A number of applications will render web pages as a small subset of their function, and those rendered pages also are unsafe. For example, the Tinfoil for Facebook application has an option to “Open links inside app”. Those are opened with the system WebKit. Banking, securities and finance apps may well do the same. If you run an Android app that handles sensitive data, ask the developers if they use WebKit/WebView. If so, do not use it on Android 4.4 or below.

From the web browsers above that pass all standards tests, Google Chrome likely has the largest installed base, as it is bundled on many Android devices when they are sold. Many will be tempted to use it as their secure browser. This is likely the wrong choice, for a number of reasons:

It's plain that the safest browser on Android should be open source, include malware block capability, receive regular updates and not be based on WebKit in any way to ensure that it does not clandestinely utilize vulnerable Android components. The obvious browser that meets these qualifications is Firefox. This is not to imply that Firefox is a perfect browser. It famously lacks a sandbox, which has not helped its reputation (www.extremetech.com/computing/178587-firefox-is-still-the-least-secure-web-browser-falls-to-four-zero-day-exploits-at-pwn2own). However, it is far better than the majority of its peers on Android. It also has a large extensions library that includes several malware/adblock options, which Google has confirmed will never come to Chrome for Android (www.omgchrome.com/chrome-android-extensions-not-planned-ama), which might be for the best, as criminals have been soliciting Chrome extension app authors to abuse Chrome users (https://software-gunslinger.tumblr.com/post/143004937538/google-chrome-a-history-of-crime).

To address other Android components that present a danger to safe usage, consider the following:

You do not want to trust your bank account to an operating system where no one cares that hundreds of bugs are ignored, regardless of enthusiasm, hype or attractiveness. Assuming that you must use your Android device to process such sensitive information, it is likely better to use a mobile HTML site in a safe browser rather than a local app. If circumstances force you to use an app, prefer an app developer that recognizes Android libraries for the security minefield that they are and thus avoids using OS features that can compromise your data.

Users of modern, enterprise Linux are accustomed to five-year support cycles on platforms with regular security updates that rely on fine-grained package databases, allowing for easy reversal of an individual patch. All of this is available for free from multiple vendors, although paid support is available through several avenues.

For such individuals, Android releases closely resemble unsupported development snapshots. In the rare events that Android updates do arrive, they come as giant .ZIP files that are slapped over (/system)/bin in an irreversible manner. Updates commonly apply new locks over boot firmware, fencing users out of hardware that they purchased and own.

Should a new enterprise Linux distribution appear exhibiting these behaviors, no one would use it. Should an existing distribution implement these policies, the exodus of the user community would likely not be as fast as the blizzard of lawsuits that tore the vendor to bankruptcy.

A day will come when consistent security policies and updates are required on embedded, mobile, workstation and server platforms. For the good of the computer sciences and the people who use them, let's hope that day comes soon.