Using Android 4.3? Don't let malware snatch your private login keys
Bad news: One in ten devices suffer KeyStore flaw. Good news: It's hard to exploit
If you're one of the 10.3 per cent of Android users running version 4.3, aka Jelly Bean, your login keys are at risk of theft – thanks to a vulnerability in the operating system's KeyStore software.
KeyStore, as the name suggests, stores a user's cryptographic keys, which are used by apps to log into services without the user having to retype their password.
But IBM researchers have found that the program is vulnerable to a classic stack-based buffer overflow by an attacker who is able to get a dodgy app running on a device. By borking KeyStore, some secure login functions could be accessed and master keys obtained.
The team notes that Google's KeyStore source code contains this harbinger of the vulnerability in the comments: "To keep things simple, buffers are always larger than the maximum space we needed, so boundary checks on buffers are omitted."
Unfortunately, applications can set the size of the data processed, meaning the buffers are not always large enough, and malicious software can therefore inject bytes into the KeyStore app's memory where it shouldn't. From there, the attacking code will try to hijack the flow of execution in KeyStore.
However, before people panic, the IBM advisory does explain that the flaw is a particularly tricky one to exploit.
An attacker would need to write an app that contained malware, convince the user to download and install it, and then evade multiple security defenses – DEP, ASLR and stack cookies – to exploit the buffer overflow and execute code within the KeyStore process. And even then some of the KeyStore information is still protected.
The IBM researchers found the flaw last September and alerted the Android security team privately about the issue. By November a fix was developed for Android 4.4, but not the Jelly Bean build, so the team sat on the problem a while longer before disclosing it.
"Considering Android’s fragmented nature and the fact that this was a code-execution vulnerability, we decided to wait a bit with the public disclosure," said Roee Hay, IBM's application security research team lead, in a blog post about the hole. ®