"Shocking" Android browser bug could be a "privacy disaster": here’s how to fix it

library
crime | hacking | security

Independent security researcher Rafay Baloch has written about a security bug in the Android Browser app that allows one website to steal data from another.

The guys over at Metasploit are calling it a “Privacy Disaster,” and promising to take the time to create a video that is “sufficiently shocking” in order to show you why.

So, what went wrong, and what should you do?

The Same Origin Policy

Web security depends very heavily on a principle known as the Same Origin Policy.

Very loosely speaking, this says that only web content (such as JavaScript) from site X can access information already sent to your browser by site X.

It’s easy for site Y to pull in content from site X, for example by using an IFRAME, or inline frame:

So attackers can easily send you a web page that causes your browser to suck in their content, mixed with my content, including important data such as session cookies.

What these attackers are not supposed to be able to do in their web code is to get hold of anything I sent to you.

The browser may display our content intermingled – when presenting a Facebook widget, for instance – but it mustn’t allow it to be mixed together programmatically.

Otherwise it would be a simple matter for crooks to put JavaScript into their pages to suck private data out of the content supplied by me (such as the abovementioned login cookies).

They could then send the stolen data back to their servers to misuse at their leisure.

Anyway, Rafay Baloch found a way of sucking in content from another site into an IFRAME, and then reading Document Object Model (DOM) data from that IFRAME using some JavaScript trickery outside the IFRAME.

Ironically, he did it by registering a JavaScript callback using a URL text string that started with a NUL, or “zero” character:

NUL is just another character in JavaScript text strings, but usually denotes the end of a string in C.

Presumably, when the Android browser validates the URL to see if it’s suspicious, it stops checking for risky content at the NUL character.

But when it actually processes the URL, it ignores the NUL byte, just as it might skip over leading tabs or spaces.

Good and bad news

The good news is that the Android Browser app, known simply as Browser, has been discontinued by Google.

You can still get hold of it and install it if you want, but Android 4.4 (KitKat) doesn’t have it by default.

The bad news is that older versions of Android (apparently, anything before 4.4) do come with Browser.

And, because Browser it isn’t being developed any more, this bug might well be there to stay, unless your phone vendor decides to offer a firmware update to replace it.

But if your phone vendor were in the habit of pushing out firmware updates, you’d reasonably expect to have Android 4.4 already and this bug would be moot.

What to do?

Stop using Browser if you have it installed.

You’ll know you have it by going to Settings | Apps | All and looking for its tell-tale icon:

You almost certainly can’t uninstall it, because it’s usually part of the operating system build itself, meaning it doesn’t show up under Settings | Apps | Downloaded.

But if you tap on Browser from the All apps page, you should see a [Disable] button where you’d usually see [Uninstall]:

This will let you disarm the danger by preventing you from using the risky Browser app again.

If you’re looking after a fleet of Androids as part of a Bring Your Own Device (BYOD) programme, a decent Mobile Device Management (MDM) product should help to defuse the risk by inhibiting the Browser app remotely:

You’ll need to provide your users with another browser in its place, of course, but your MDM software should make that pretty easy, too.