Attackers can pwn 60% of Android phones using critical flaw

And don’t expect a fix anytime soon.

Attackers can pwn 60% of Android phones using critical flaw

Attackers can gain complete control over 60 percent of Android phones using a critical flaw.

First discovered by researcher Gal Beniamini, the vulnerability (CVE-2015-6639) allows an attacker to execute code within Qualcomm's Secure Execution Environment (QSEE).

You see, most mobile platforms come pre-installed with a trusted environment for executing code that is segregated from the normal operating system. This environment is created by TrustZone.

QSEE refers to Qualcomm's implementation of TrustZone. As such, it is divided between two environments: the "Non-Trusted" and "Trusted" worlds.

Trusted execution

The operating system and mobile applications function in the "Non-Trusted" world, whereas more sensitive functions (such as the processing of cryptographic keys and encrypted data) take place in the "Trusted" world.

Those two realms are supposed to remain separate except during development. But Beniamini has detected a method by which attackers can gain access to the "Trusted" world from the "Non-Trusted" world. All they need is a vulnerable "trustlet," or trusted application:

"...Communication with TrustZone exposes a large (!) attack surface - if any trustlet that can be loaded on a particular device contains a vulnerability, we can exploit it in order to gain code execution within the trusted execution environment. Moreover, since the trusted execution environment has the ability to map-in and write to all physical memory belonging to the 'Normal World', it can also be used in order to infect the 'Normal World' operating system's kernel without there even being a vulnerability in the kernel (simply by directly modifying the kernel's code from the 'Secure World')."

As it turns out, the security researcher discovered one such vulnerable trustlet: widevine, a trusted application in Android's mediaserver which enables playback of digital rights management (DRM) encrypted media.

By exploiting that vulnerable trustlet, the researcher can in a sense bypass the Linux kernel entirely and gain access to QSEE, as illustrated in the graphic below:

Minas tirith

Following his discovery, Beniamini tested several Android devices and found them to be vulnerable, but it was unclear just how many separate phones were affected by the critical vulnerability.

That's not the case any longer.

Kyle Lady, product R&D at Duo Security, measured a data sample of 500,000 Android devices running the security firm's 2-step verification app. Out of those phones he analyzed, 60 percent were found to be vulnerable.

Not only that, but 27 percent of those devices were found to be "permanently vulnerable" in that they are too old to receive monthly updates. In that case, those devices can be protected only via an OS upgrade to at least Android 4.4.4 or by receiving a patch from the carrier on that version and model.

That latter fix is unlikely. Even on newer models that receive patches on a monthly basis, it's unlikely users will receive the update anytime soon. As Lady told CSO:

"There really isn't any way for them to force a patch to happen," he said. "If it isn't a Nexus phone, the manufacturer has to apply the patch to the software, then send it to the carrier, such as Verizon. The carrier has to approve it, and then send it to customers using that phone. So there's a substantial delay."

Screenshot from 2016 05 01 18 46 50

Let's be clear. This vulnerability isn't as serious as something like Stagefright. This flaw does in the very least require attackers to trick a target into downloading a malicious application on their Android device.

As a result, while users await a fix for their Android model and version, they should install applications from only trusted sources. They should also regularly check their devices for security updates and implement them as soon as possible.

Tags: ,

Smashing Security podcast
Check out "Smashing Security", the new weekly audio podcast, with Graham Cluley, Carole Theriault, and special guests from the world of information security.

"Three people having fun in an industry often focused on bad news" • "It's brilliant!" • "The Top Gear of computer security"

Latest episode:

,

6 Responses

  1. TMC

    May 23, 2016 at 2:57 am #

    And like countless times before, the FCC will do nothing about filthy-rich carriers intentionally ignoring this massive threat to thier own customers; not even a wrist-slap. Their only suggestion being “buy a new phone!”.

    • Bob in reply to TMC.

      May 23, 2016 at 4:05 pm #

      It's not a carriers responsibility, is it?

      I can even sympathise with manufacturers because once they've sold it there's more effort involved in making future fixes backwards compatible. They want you to buy a new phone; that's how the 'buy it cheap' Android business mode works.

      Carriers are in the business of providing the mobile service (and sometimes the phone) but why should they be responsible for ensuring its updated? Intentionally blocking updates is a different matter which only should be done, in my opinion, when it would compromise usability.

      It's one reason why people are foolish to use Android if they care about security given how poor Google's track record is. On the other hand both Apple and Windows Phone receive regular updates and the majority of users are running the latest version.

  2. John

    May 24, 2016 at 1:18 am #

    There is an easy fix for this. Never ever buy Android phones again as long as Samsung, HTC etc. don't have a better update system in place. These phone pushing vendors obviously think security updates is just a joke and un-necessary burden. When a new security problem arises, just buy a new phone is their philosophy.

  3. Rob

    May 24, 2016 at 1:36 pm #

    Is this exploit Qualcomm specific, or does it or a variant affect Mediatek, and Spreadtrum Socs also?

    • Bob in reply to Rob.

      May 24, 2016 at 8:32 pm #

      If Mediatek implement QSEE in the same way as Qualcomm then yes, they too are affected.

      I'd copy and paste the code but it's a screenshot but I can't however the answer to your question (the 'proof') can be found within the source article:

      http://bits-please.blogspot.co.il/2016/05/qsee-privilege-escalation-vulnerability.html

  4. Faz Mohammad Faqiry

    February 8, 2017 at 6:37 am #

    The Security is not a concern for Google itself. the security is the main concern for the users of Android Devices. The reason which Google does not pay a serious attention in is, if Google put another mechanism for Google Bouncer as it is using offline Apps verification. Offline Apps verification can not resolve the security issue as Dynamic code loading is common question against Google Bouncer.

Leave a Reply