Serious Android crypto key theft vulnerability affects 10% of devices

Bug in Android KeyStore that leaks credentials fixed only in KitKat.

Researchers have warned of a vulnerability present on an estimated 10 percent of Android phones that may allow attackers to obtain highly sensitive credentials, including cryptographic keys for some banking services and virtual private networks, and PINs or patterns used to unlock vulnerable devices.

The vulnerability resides in the Android KeyStore, a highly sensitive region of the Google-made operating system dedicated to storing cryptographic keys and similar credentials, according to an advisory published this week by IBM security researchers. By exploiting the bug, attackers can execute malicious code that leaks keys used by banking and other sensitive apps, virtual private network services, and the PIN or finger patterns used to unlock handsets. The advisory said Google has patched the stack-based buffer overflow only in version 4.4, aka KitKat, of Android. The remaining versions, which according to Google figures run 86.4 percent of devices, have no such fix. In an update, IBM said the vulnerability affected only version 4.3, which runs on about 10.3 percent of handsets.

There are several technical hurdles an attacker must overcome to successfully exploit the vulnerability. Android is fortified with modern software protections, including data execution prevention and address space layout randomization, both of which are intended to make it much harder for hackers to execute code when they identify security bugs. Attackers would also have to have an app installed on a vulnerable handset. Still, the vulnerability is serious because it resides in KeyStore, arguably one of the most sensitive resources in the Android OS. In an e-mail, Dan Wallach, a professor specializing in Android security in the computer science department of Rice University, explained:

Generally speaking this is how apps are going to store their authentication credentials, so if you can compromise the KeyStore, you can log in as the phone's user to any service where they've got a corresponding app, or, at least, an app that remembers who you are and lets you log back in without typing a password. This means that most banking apps, which force you to type your password every time, are probably safe against this particular attack.

The amount of damage you can do, then, has a lot to do with which apps this lets the attacker compromise. If the attacker can compromise your Twitter account, then yeah, they can spew spam in your name. Not very exciting. If the attacker can get anywhere near your money, then it gets more interesting. Likewise, for companies that load VPN credentials into your phone, so you can connect through their firewall to their internal services, there could be a variety of nasty attacks, since you've effectively given the attacker the keys to get through the firewall.

Pau Oliva, senior mobile security engineer at viaForensics, said the vulnerability could pose other threats, since it allows attackers access to the Android resource that performs sensitive cryptographic operations.

"A malicious user exploiting this vulnerability would be able to do RSA key generation, signing, and verification on behalf of the smartphone owner," Oliva told Ars.

In addition to snuffing the vulnerability in Android version 4.4, it wouldn't be surprising if Google offered additional protections through the Bouncer service that scours Google Play for malicious apps. Presumably, it wouldn't be hard to introduce code that closely scrutinizes apps that involve the KeyStore. Then again, malicious and abusive apps bypass the protective Bouncer filter on a regular basis, and white-hat hackers in the past have identified key weaknesses in Bouncer. Android users who rely on their devices for managing money and storing confidential information are once again advised to carefully vet apps before installing them and to think long and hard before installing apps available in markets outside of Google Play.

Promoted Comments

I don't know why some people are complaining about AppOps. There is no "exploit buffer overflow" permission in Android It has precisely nothing to do with this thread.

Anyway, looking at the actual vulnerability, its described as "theoretical" and probably this is the reason why:

show nested quotes

Encoding. Characters below 0×30 (’0′) or above 0x7e (‘~’) are encoded before being written on the buffer.

So you can overflow the buffer, but if you do, your injected code is converted to ASCII 7 bit, meaning that the most significant bit of every bit is set to 0, and you can't encode values less than b'0011000. So basically, you can set each word to values of the form b' 0xxxxxxx 0xxxxxxx 0xxxxxxx 0xxxxxxx. How big of a deal is that? Pretty big actually.

Take a look at this chart:

Right away you can see that all condition codes must start with a 0. That immediately throws out "always execute". So every instruction you encode will be conditional.

Thats not great, but you can probably deal with it. Also annoying, your Rd register always begins with a 0, so you can only write to half of the available registers. That can probably be worked around too. You also can't do multiply instructions. I guess add in a for loop

Where it gets ugly is the comparison instructions. All of them require a non ASCII byte. So you can't compare things. Finally, while you can issue an ADD, the values you can add are constrained by the requirement that they not include ASCII values below 0x30, so depending on what operand you do you can only pass in certain values.

I think in practice its going to be almost impossible to write code that does anything because you can't use most of the instructions, write to most of the resisters, and your immediate operands are sharply constrained.

Where this probably matters is on x86, where instructions don't have to be word aligned. Fortunately, at the moment there are almost no x86 Android devices.

Im amazed that in this day and age we are still getting pwned by buffer overflow attacks.

Are we, though? I have yet to read an article about Android vulnerabilities on Ars that describes a real-world problem. It's always some obscure research lab that has invented some implausible situation. The title is pure flame-bait too, present simple tense is normally not used to describe hypothetical situations.

Its unclear if this is exploitable as far as I can tell, and if it is not, only by dumb luck. However, its definitely a buffer overflow, and one in relatively recently written code. That it is even possible (and in cryptography-related code no less!) is should be embarrassing, even if it may not actually be all that dangerous.

Still sticking with pre-4.4.2 until they return access to the App Ops (Permission Manager) service to users of the newer OS versions.

Up until 4.4.2 you could run an app like App Ops Starter to trigger the service that allows you to manually disable specific permissions for individual apps when you didn't want specific installed apps to have those permissions. This is beautiful because you can still have the apps you want but also disable permissions you feel they don't really deserve.

Yes, certain apps do need access to certain permissions to function properly, but you couldn't even run the service without first triggering it through an app that is specifically designed to trigger it, so the risk was minimal that people would break their own apps. And if you're messing around with disabling permissions, you can figure out which those are pretty quickly. The whole point is to give the user more control over their security and their device.

But in newer versions of the OS they took access to the App Ops service away completely, so you can no longer control the individual permissions that apps want, at least not without jailbreaking which I have no interest in doing.

Since with the newer OS versions you can no longer simply disable individual permissions from apps that you've installed, I'll wait until they allow us to do that again, which will probably never happen. I don't use banking services on my phone anyway, so whatever. And most people never even knew they had the ability to control app permissions so granularly, so of course there's very little demand for that control to be returned to the user and Google will ignore the request. =\