BWAIN of the week is “Quadrooter,” a security problem that gets its name because it’s a collection of related vulnerabilities that gives four different ways of getting root-level access on an Android device.

(The word BWAIN, in case you missed it when we first rolled it out, is our just-a-bit-cynical coinage to describe a Bug With An Impressive Name, such as Heartbleed, BREACH, Stagefright and, more recently, HTTPoxy.)

Strictly speaking, Quadrooter isn’t a bug in Android itself, but in various add-on software components supplied by Qualcomm, makers of popular chipsets used by Android phone manufacturers.

Outside the Apple world, where Apple supplies both the hardware and the operating system software for its laptops and mobile phones, it’s quite usual to run an operating system that is a mixture of software from the vendors of the hardware that’s in your device (e.g. CPU, screen, USB bus) and the makers of the core operating system itself.

On a Windows laptop, for example, you may find that a default install works OK, but that some parts of the system don’t work fully or efficiently until you update their drivers from the individual hardware vendors involved.

On Android, you will typically get an “all in one” firmware build – known by the delightfully descriptive acronym BLOB, short for binary large object.

In other words, if you buy a phone with a Qualcomm chipset, you will typically end up with an operating system kernel that is a pre-cooked mixed of code from Google’s Android project, Qualcomm’s chipset-specific support, and the phone manufacturer’s own tweaks.

So, digging for kernel bugs in the Android codebase alone isn’t enough, and that’s why security researcher Adam Donenfeld from Check Point decided to turn his attention to Qualcomm’s code as well.

The Quadrooter bug family was revealed at the recent DEF CON conference in Las Vegas.

The good news is that the bugs that Donenfeld found have already been fixed:

The research team provided Qualcomm with information about the vulnerabilities in April 2016. The team then followed the industry-standard disclosure policy (CERT/CC policy) of allowing 90 days for patches to be produced before disclosing these vulnerabilities to the public.

Qualcomm reviewed these vulnerabilities, classified each as high risk, and confirmed that it released patches to original equipment manufacturers (OEMs).

Another silver lining is that although the Quadrooter bugs allow an attacker to trick the kernel into doing things it shouldn’t, such as bypassing or changing critical security settings, the bugs aren’t remote code execution (RCE) holes.

In other words, attackers can in theory use the Quadrooter vulnerabilities to promote a regular app to an all-powerful one, but they can’t use the holes to trick you into installing a malicious “regular app” in the first place.

That’s in contrast to the Stagefright BWAIN that was announced at Black Hat 2015, where a bug in Google’s own code meant that a booby-trapped image on its own was, in theory, all that a crook needed to attack your Android.

Simply put, Quadrooter means we’re looking at an elevation of privilege (EoP) exploit that requires an attacker to infect you with malware first.

Nevertheless, EoP bugs on Android are always troublesome, because it means that the crooks can tempt you with a really simple-looking app that asks for no special security permissions at all.

An app that avoids any extra permissions certainly gives the impression of being low-risk.

After all, it’s reasonable to assume that if an app can’t access your microphone and can’t communicate over the network, then it can’t possibly bug your phone, either.

An EoP exploit changes those rules, because an app that starts out looking entirely innocent may be able to “get root”, and from there not only to grant itself permissions you never gave it yourself, but also to sidestep its own removal so that it stays behind even after you uninstall the original app.

The bad news, as so often in the Android ecosystem, is that even though Qualcomm has provided patches to its customers, it can’t easily force those customers – the phone makers – to pass the patches on to end users.

That’s one reason why two US regulators, the FCC and the FTC, are starting to ask tough questions aimed at speeding up the process and reliability of Android security updates.

What to do?

• Don’t panic. Stagefight attracted just as much media attention, and in theory could have allowed 950,000,000 Android devices to be hacked with a single message. The fact that Quadrooter could apparently allow up to 900,000,000 Android devices to be rooted without permission is therefore not a vulnerability with an unprecendented reach.
• Stick to Google Play. It isn’t perfect, but Google does put plenty of effort into preventing malware arriving in the first place, or purging it from the Play Store if it shows up. In contrast, many alternative markets are little more than a free-for-all where app creators can upload anything they want, and frequently do.
• Consider using an Android anti-virus. By blocking the install of malicious and unwanted apps, even if they come from Google Play, you can spare yourself lots of trouble.
• Avoid apps with a low reputation. If no one knows anything about a new app yet, don’t install it on a work phone, because your IT department won’t thank you if something goes wrong.
• Patch early, patch often. When buying a new phone model, check the vendor’s attitude to updates and the speed that patches arrive. Why not put “faster, more effective patching” on your list of desirable features, alongside or ahead of hardware advances such as “cooler camera” and “funkier screen”?