Another Android hole: “OCtoRuTA” – One (Java) Class to Rule Them All

– Unico Anello (one ring) image by Xander via Wikimedia Commons –

Yet another large-scale vulnerability has been revealed in Android.

This one was discovered by IBM researchers, reported to Google, and patched.

That done, the hole is being presented at this week’s USENIX WOOT 2015 Conference, in Washington, DC.

On paper, this one isn’t quite as bad as Stagefright, which allowed for remote code execution (RCE) triggered in a number of ways, such as receving an MMS message.

But the new hole, officially designated CVE-2015-3825, is bad nevertheless.

Elevation of Privilege

The CVE-2015-3825 vulnerability allows for elevation of privilege (EoP) right up to system level.

In other words, an innocent-looking app that you decided to trust, perhaps because it asked for a respectable and limited set of privileges up front, could go totally rogue.

By exploiting this hole, an apparently harmless app could grab hold of the the right to do any or all of the following:

• Steal data from other apps.
• Access the network to exfiltrate stolen data.
• Replace already-installed packages with imposter apps.
• Install malicious kernel modules.

This vulnerability inspired some wordplay by Or Peles and Roee Hay, the researchers who wrote it, who entitled their paper One Class to Rule Them All.

The joke (if we can use that word) is that a bug in a single Java component – known to programmers as a class – in a single app could turn into an exploitable loophole against any app.

We’ll call it OCtoRuTA for short.

Subverting other apps

OCtoRuTA means that a single malicious app could subvert the security of most of, if not all, the other apps on your device.

This vulnerability is complex to explain in a few sentences, but we’ll try anyway.

Sharing data safely between apps can be tricky, especially if those apps are be written in different programming languages, or could run on completely different computer systems that represent data differently in memory.

For example, if I want to hand over a file full of data to your program, I could simply provide a filename (e.g. mystuff.dat) or even just a file handle, usually stored as an index number (e.g. 7) by many operating systems, and leave you to read the data back in.

But what if you can’t read file number 7?

What if your process treats file number 7 simply as the data “7”, or what if you’re on a completely different computer, where mystuff.dat refers to a totally different file?

The answer is serialisation, where program A explicitly collects up and writes out all the actual data it wishes to transfer in a standardised format, rather than just providing references to it such as memory addresses or file handles.

Android “Parcels”

In the web world, I might write the data in an interchange format such as JSON; in the Android world, I might use a system called a Parcel.

Actually, Android Parcels are a strange sort of serialisation, or “flattened data,” as Google calls it.

Parcels can refer to what are known as live objects, meaning that the data may well have changed by the time program that deserialises the data, or “unflattens” it, actually gets around to using the parcel.

So there is some fancy footwork needed in the Parcel system: when Process B “unflattens” data from Process A, that data may not only have changed, but even no longer exist. (In fact, Process A may no longer exist, either.)

Indeed, the researchers noted that programmers using Parcel objects need to be careful to label impermanent data objects of this sort by tagging then with the fancy marker transient.

You can guess where this is going.

A programmer who forgets the transient tag when it’s needed is a bit like an immigration officer who forgets to put an expiry date on a temporary visitor’s visa stamp: it’s the sort of mistake that lends itself to legitimate-looking abuse later on.

By searching for Java classes that made this mistake, the researchers were able to find a loophole by which a malicious Process B could trick Android into “unflattening” data from a privileged Process A using program code supplied by unprivileged Process B.

In short, OCtoRuTA: One Class to Rule Them All.

→ Ironically, the buggy class that the authors used in their paper was called OpenSSLX509Certificate, putting what amounts to a cryptographic flaw into the limelight yet again.

Loosely put, even an app that announces itself with no special privileges at all, and thus sounds as though it’s safe to take a chance on, could promote itself and enjoy privileges normally restricted to the trusted parts of Android.

What to do?

The researchers disclosed this bug responsibly.

So, Google has apparently already worked out a patch for the underlying flaw (presumably by no longer relying on the programmer to make the right choice about transient data objects).

With this in mind, here’s what you can do:

• Stick to Google Play. Although Play is far from perfect, it’s at least possible that Google has added some sort of extra scrutiny to its automated app approval system to look out for apps abusing the OCtoRuTA hole. Unsupervised alternative markets, or apps promoted via links sent in an SMS or email, are a more likely hunting ground for crooks who cotton onto this exploit.
• Watch for Android updates. Now that at least Google and Samsung have promised regular (and frequent) security updates, you need to make sure you’re getting them as quickly as you can.
• Consider using third-party Android anti-virus software. The OCtoRuTA bug can’t be remotely exploited, so attackers need to get malware on your device in the first place in order to deliver the next round of malware. A real-time malware filter can help you avoid infection in the first place.
• Read reviews and user feedback before trusting new apps. But beware: anyone can post Google Play reviews, good or bad, without a shred of truth in them. So be cautious of skimming through reviews until you find someone saying what you want to hear.
• Ask vendors or carriers to tell you when their OCtoRuTA patches will be ready. Right now, we have a collective opportunity to urge the Android ecosystem to take a more proactive attitude to updates and update annoucements.