Serious Security Bugs Found In Android Kernel 230
geek4 writes with this excerpt from eWeek Europe: "An analysis of Google Android Froyo's open source kernel has uncovered 88 critical flaws that could expose users' personal information. An analysis of the kernel used in Google's Android smartphone software has turned up 88 high-risk security flaws that could be used to expose users' personal information, security firm Coverity said in a report published on Tuesday. The results, published in the 2010 edition of the Coverity Scan Open Source Integrity Report, are based on an analysis of the Froyo kernel used in HTC's Droid Incredible handset. ... While Android implementations vary from device to device, Coverity said the same flaws were likely to exist in other handsets as well. Coverity uncovered a total of 359 bugs, about one-quarter of which were classified as high-risk."
Bug bounties? (Score:1, Interesting)
How much are these worth in bug bounty money?
Android or Linux (Score:5, Interesting)
Apparently no word on whether these are flaws in the vanilla kernel which Google has inherited, or flaws in the code that Google wrote.
coverity's mindless drivel (Score:5, Interesting)
Those "critical" and "serious" label are largely meaningless; Coverity allows you to configure classes of "problems" as being one of several different severity. It is what the sysadmin of Coverity wants it to be. If so desired, buffer overflow could be configured to the severity of "minor."
coverity is a great tool. (Score:5, Interesting)
we use it at .
Coverity is the commercial offshoot of the old Stanford Checker that found something like 2500 critical bugs in the linux kernel back when it (the checker) was just a grad school project. the bugs got fixed very quickly and linux was better for it.
that said, Coverity's definition of serious or critical is not necessarily what most developers could call critical (haven't read the bug list, but from personal experience.....)
in any case, this is a win. these bugs are now known, and google/community will fix them within days if they haven't already been fixed (I hope Coverity had the decency to inform google prior to their press release)
High False Positive Rate (Score:5, Interesting)
Coverity uncovered a total of 359 bugs, about one-quarter of which were classified as high-risk.
Based on my experience using Coverity's tools, more than half are actually false positives and less than half of what's left are really as serious as rated.
Re:this is a Success for open-source! (Score:5, Interesting)
They are outed, and so get fixed even faster.
Well, sort of. Even if they get fixed quickly by developers, the time it takes them to actually get fixes to consumer devices is huge. That deployment process relies on device manufacturers who often customize the OS a bit per-device and cell carriers who have to push out the updates. For them it's just an expense/loss of resources, so unless it's something really serious they don't even seem to put much effort into it.
Re:The most interesting thing about that article.. (Score:3, Interesting)
I must be missing the link to the study results. Oh, won't be out until next year, to allow for patching.
So, maybe something, maybe nothing.
There are better release from Coverity's site, http://coverity.com/ [coverity.com]
Re:Ok... (Score:5, Interesting)
Odd, I don't know why you're picking on me, but I assume "Android Kernel" is marketing-speak for "Linux", in which I've reported found and fixes dozens of flaws over the years.
As you're so interested, here are some from the last month or two that you can take a look at.
CVE-2010-3080, A use-after-free in snd_seq_oss_open
CVE-2010-2960, A to-userspace dereference in keyctl_session_to_parent.
CVE-2010-2954, Kernel panic and to-userspace dereference in AF_IRDA sockets.
CVE-2010-3067, Various problems with aio (things like aio_submit())
The coverity results I've seen in the past are generally very low quality with a high density of chaff. I haven't seen the report they're talking about, but would be surprised if there were any noteworthy findings with any significant security impact. The only report I've seen them publish that had any convincing vulnerabilities was in 2006, where they found a verifiable privilege escalation in XFree86 (due to a pretty horrendous typo).
I'm a little saddened that you so readily associate me with Windows security, where as I consider myself primarily a Linux security developer, but I guess I'm flattered that where I spend my time is so important to you.
(perhaps a little creepy, though).
Re:Should have waited (Score:3, Interesting)
Re:Is it just me? (Score:4, Interesting)
Android uses outdated kernels in every release. Those issues are like "Hey grab a bugfix list from the latest kernel and write a study in which you supposedly hunted down these bugs yourself".
It's like an unpatched Vista Service Pack Zero and then reporting about bugs that have already been fixed...
Most of these aren't really going to be an issue (Score:3, Interesting)
There's a function that helps avoid exploitation of the vulnerabilities in the API.
developer.android.com/reference/android/app/ActivityManager.html#isUserAMonkey%28%29
Just ensure that it's returning false and you should be safe.
Re:The most interesting thing about that article.. (Score:5, Interesting)
Depends on your definition of OS. There's more than 1 definition, one of which translates to "the kernel" and another translates to "everything that comes with a computer", and a couple in between. When most technical people say OS, they mean the program that controls access to the hardware and provides system services- the kernel. By that definition Android is a framework on top of the OS. And in functionality it's far closer to a window manager than a kernel.
Re:this is a Success for open-source! (Score:3, Interesting)
Thats why manufacturers should be in control of updates and not carriers.
Manufacturers should be the ones to release updates (though a manufacturer provided update system). Apple did it and it works GREAT (and Apple doesnt have to delay updates waiting for "carrier acceptance" or whatever BS the carriers want to do)
Then we wont have situations like the Telstra branded HTC Desire where the manufacturer has released an update for the phone but the carrier is deliberatly holding up the release of the update.
Re:this is a Success for open-source! (Score:1, Interesting)
I guess that is why Google Phone will fail. Google wanted someone else to pick up the hardware end of it and now they don't have a way to patch anything directly ala Apple.
Re:88 critical flaws (Score:3, Interesting)
This article sure looks suspect coming from someone at a place with a name like PageOnePR?
Going to their site it is clear the business is about promoting branding on social web sites.
This isn't a group of coders working on improving quality. It's about PR and headlines.
It's obviously not Android or open source that they're promoting.
My money is on MS-funded FUD just as the MS phone is about to ship...
Re:Ok... (Score:5, Interesting)
Odd question.
I don't know about three days, but certainly under a week, which is completely normal in free software. Proprietary vendors generally want between six months and two years, but free software vendors and projects very rarely ask for more than a week or two delay before publication.
In fact, Linus famously tells people not to tell him about any security issue you want kept secret for more than a week, as he will just go ahead and fix it.
A better look at it (Score:2, Interesting)