Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

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."

the once flagship N1 that I own (and still use since it still mostly works) has been abandoned long ago and I hate google for it.

this is yet another reason not to trust them. I don't care about new features, but porting security fixes should be a must-do for them, given how HUGE that company is. they have endless pockets and can easily afford to keep just a few guys (at least) busy keeping the old google flagship models updated.

One difference between enterprise software companies and consumer software is that over 50% of the enterprise revenue is for support. Virtually none for consumer software because people are unwilling to pay for it and the product lifetime is short.

In your opinion, how long is it reasonable for a software developer to provide patches for software?

I do agree that the updates situation in Android-land is/was pretty ugly (it seems to be improving) but expecting patches for a 4 and a half year old product that was obsolete around 2.5 to 3 years ago? If any software developer were to start doing that, they'd have to build the cost into the price of the product (no, it would not be negligible). I personally think upgrading products for 18 months post rele

old 2.x android which still works for audio phone and email and simple web (which is 99% of what many users want, actually). but has no security patches from google since the last OTA update was at least 3 yrs ago, maybe more.

google abandons things. it may not be pleasant for fanboys to admit, but its a fact and its part of why I have so much anger toward google. they are not serious. not by my definition. 5 yr old hardware that needs security SHOULD get security updates. even 10 yrs. again, this is the money and power and brain-rich google we're talking about. they do NOT get a pass on being bad about backporting security. a 10 or 100 man company, sure. but google gets no free pass on abandoning their own phones (my case, the N1). total complete abandonment. even the gmail app BY google refuses to work properly on the N1, now. it does not auto poll and show newmail indications. you have to manually poll. a google app on a google phone that is broken. this is why I hate them.

as others have said, i'd call bs until i heard a model associated with this. Did you buy it new? off Ebay?my wife's iPhone 4 is close to 4 years old, can run iOS7 (though never get ios8) and gets security updates.

Apple sees value in the software ecosystem. They want everyone on the latest OS so you can buy more apps from the Apple store. Google wants to sell you ads. The difference in perspective is why I lean iOS,

That was a new $700+ iPad, from the Apple Store in the summer of 2010 about five months after launch.

That's certainly a nerd sort of pedantically correct, but the scope and scale matter a lot. Apple is far, far better about updating old devices. Anyone who tries to argue that they are equivalent to Google on this front is just being an asshole.

Yes, there are a few models that did not get more than two years of OS updates due to hardware limitations (or business reasons if you want to think that) and the iPad you mention is one of those.

If we compare to Android, the majority of all Android devices have *ne

Sounds like you want to compare the cheapest android devices with the most expensive apple ones. The more expensive android devices are much more likely to keep getting updates. And if they're a Google branded device, even when official updates end there's a community to support it. That's why a four year old Nexus One can run Android 4.4 today.

I bought an iPod Touch 4 in that time period. About two years ago now. Unsupported on iOS 7. Big mistake on my part. I guess I should have stood in line outside the Apple store instead of just going to WalMart and buying what was considered the current Apple iPod Touch.

People like to beat up Android for ongoing support of devices, but Google is no different than Apple and other companies in this respect. The Nexus One was contemporary with the iPhone 3G, which was only supported up to iOS 4.2.1, released in June 2010, on the same day that sales of the iPhone 3G were discontinued. Nexus One was supported until Android 2.3.7, which was released around a year after sales were discontinued.

Actually Apple is generally much better that Google in this regard. While you can find a few Apple devices that got relatively short support (especially early models), typically most devices now get about 4 years of updates. The iPhone 4, released in 2010, still getting updates though that will stop when Apple releases iOS8 in September. The iPad 2 released in 2011, still getting updates and will get iOS 8.

They are getting 4 years of updates, because Apple is keeping them on the shelf for 3 1/2 years. iPhone 4 got iOS 7, because it was still on the shelves when it was announced (though taken off the shelves on the day it was released). The original iPad, which came out 3 months earlier with much the same level of hardware, did not even get iOS 6, because it was withdrawn from sale as soon as the iPad 2 came out.

The main difference here is the rate of release of new phones. Apple likes to keep 3 models of i

Third party firmwares patch this. However it's the carriers and manufacturers who lock down bootloaders, void warranties, and refuse to allow a more open environment that refuse to make additional changes or updates. I've got a Note 2, it was updated by Samsung nearly a month before Verizon could come out with the update and that was delayed quite a bit from when Google released 4.4.2.

You can blame Google all you want, but it's an Open Source OS and patches can be backported by anyone. Sadly the only pe

Yes. It is trivial to make data structures that do bounds checking automatically. I remember this being on by default in Pascal in the 80's. Those who prefer speed over security won long ago. Why slow down a processor that can only do 1 billion instructions per second with an extra test and branch?

No bounds checking? In a security module of Android? Duh! What sort of idiots do they have coding this thing?

Agile idiots. It passed the test suite written by other agilistas, so no QA needs to be performed. Just ship it. Put bounds checking into the backlog. If someone can come up with a good user story like "86% of all devices we've shipped are vulnerable" maybe we'll fix it in the next sprint.

It's not just agile. Anyone dumb enough to label how they do their job with some shitty buzzword is going to be dumb enough to blindly stick to that ill-defined structure, despite it having little to do with getting the job done.

Are you sure it's not Waterfall idiots? They don't seem to release regularly at all. Proper waterfall processes are prone to the pesticide paradox when it comes to QA because everything is meant to be planned out in advanced.

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.

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 [googlesource.com] to, say, android 4.3 and below? Is there a contract with Google forbidding this? Do they get money from NSA?

It isn't part of their business model. There are tens of millions of android devices that have simply been abandoned because the business model is to sell moar phones and money spent on improving phones that have already been sold not only does not sell moar phones, it gives people less reason to buy moar phones.

Google's business model is to drive people to Google's services. That's why most of those services get back-ported to older versions of the OS. It makes more sense to back-port than to expect people to replace expensive hardware more often than every few years.

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 [googlesource.com] to, say, android 4.3 and below? Is there a contract with Google forbidding this? Do they get money from NSA?

Backporting it probably isn't difficult, but getting all the vendors and carriers to patch, build, validate, and deploy their custom Android builds for all the various devices they have supported over the last few years is.

Backporting it probably isn't difficult, but getting all the vendors and carriers to patch, build, validate, and deploy their custom Android builds for all the various devices they have supported over the last few years is.

Google knew the problem early enough to have designed their Market app to allow for a system 8 times its old size. Forcing in a binary for a 30 line kernel patch is not be a [technological] problem.

Here is a little secret. Despite their "we don't fix old stuff" stand, they don't keep their hands out of my phone with updates to things I DO NOT WANT UPDATED. I reset my phone to factory once or twice a year when I'm fed up with the puny 256MB ram design where even apps you aren't using count against your text,

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 [googlesource.com] 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/ [googlesource.com] -- 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.)