Slashdot Mirror
KeyStore Vulnerability Affects 86% of Android Devices
jones_supa (887896) writes "IBM security researchers have published an advisory about an Android vulnerability that may allow attackers to obtain highly sensitive credentials, such as cryptographic keys for some banking services and virtual private networks, and PINs or patterns used to unlock vulnerable devices. It is estimated that the flaw affects 86 percent of Android devices. Android KeyStore has a little bug where the encode_key() routine that is called by encode_key_for_uid() can overflow the filename text buffer, because bounds checking is absent. The advisory says that Google has patched only version 4.4 of Android. There are several technical hurdles an attacker must overcome to successfully perform a stack overflow on Android, as these systems are fortified with modern NX and ASLR protections. The vulnerability is still considered to be serious, as it resides in one of the most sensitive resources of the operating system."
Because the word scares people? Has it been exploited in the wild? And good luck updating all the Android devices.
Something new that's compatible with most people's version of Android.
No bounds checking? In a security module of Android? Duh! What sort of idiots do they have coding this thing?
Whoever wrote that doesn't know what "a little bug" means. Sounds like a major security bug to me.
By "affects" do you mean "puts Android users at risk"? Not that you shouldn't be careful, but everyone is going to be nuked by a bug.
I can understand if Google wants to force vendors to update to the most recent android. However, from a vendor perspective, what's so hard about backporting this patch to, say, android 4.3 and below? Is there a contract with Google forbidding this? Do they get money from NSA?
A rookie mistake. Tools to trap this have been around for ages. And do not give the "but they were optimizing" excuse. The only thing a security module should be optimized for is security. Once again, a rookie mistake.
putting the 'B' in LGBTQ+
Im amazed that after all the years and years of buffer overflow caused vulnerabilities that we are still repeating history time and time and time and time again.
I don't think old devices are vulnerable, and while 4.3 devices are vulnerable, most of them have an additional countermeasure in place that should protect against any actual disclosure of private keys.
In older devices, it looks like prior to changing keystore to use the Binder API the bounds checking was done at a higher level in the call stack, so the code isn't actually vulnerable. When keystore's API was changed to be Binder-based, that checking was lost, enabling the bug. Looking at the git log, the Binder keystore API was merged in November 2012 which I believe means that only 4.3 devices are vulnerable. It appears the bug was identified and fixed before 4.4 was released.
But most 4.3 devices, at least from major vendors, have hardware-backed key storage. All Nexus devices do. They're vulnerable to the bug, but the private keys are completely inaccessible to the Android userspace and kernel, so there's no way the key material can be leaked. To see if your device has hardware-backed key storage go to Settings -> Security and scroll down to "Credential Storage". If it says "Storage type Hardware-backed", then keystore private keys are not accessible to the Android OS userspace or kernel, so there's no way they could leak.
One caveat: Until 4.4 (I think), only RSA keys could be managed by secure hardware. So DSA and ECDSA private keys in 4.3 device keystores could leak via this vulnerability. In the future we should have support for all sorts of keys in secure hardware (https://android-review.googlesource.com/#/c/97651/ -- yes, I'm the author of that CL), as well as a mechanism for checking the hardware vs software storage question on individual keys.
I'm not trying to say this wasn't a pretty serious error on Google's part. Even with the bounds check higher in the call stack, it should have been done in keystore as well. Security-sensitive code like this should take a belt-and-suspenders approach, not depending on validation done at other layers, specifically because stuff at other layers changes. Actually, I know the guy who wrote it and that is the way he thinks, too, so I'm somewhat surprised he wrote this bug.
(Note: I recently joined the Android security team, and it looks like I may be the maintainer of keystore. I am taking the lead on hardware-backed key storage. However, I should mention that I'm not speaking in an official capacity, just someone who knows the code a bit and took a few minutes to look through the git logs.)
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
A new smartphone should be purchased every year anyway.
Google has no SQA at all. They have said so many times. Software is released UNTESTED as soon as the developer (who are usually nothing more than a resent graduate with little to no experience in real life) say it is ready.
The end result is that Android is the new Windows ME.
This has nothing to do with google, they don't have control of patching existing phones (well, not until the most recent point release of android).
Even if they did backport the fix, the phone venders wouldn't do shit.
You hit the nail on the head. Don't forget everything that's exposed to any developer for Android. They know what you looked at, where you are, who you're near, what you texted, when you're appointments are, what you searched on and the fact the user wears rubber underpants.