Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Bug Cellphones Google Handhelds Open Source Security IT Linux

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."
This discussion has been archived. No new comments can be posted.

Serious Security Bugs Found In Android Kernel

Comments Filter:
  • by Anonymous Coward on Tuesday November 02, 2010 @06:49PM (#34106680)

    88 Critical flaws on the wall... 88 critical flaws... You take one down, pass it around...

  • by ruiner13 ( 527499 ) on Tuesday November 02, 2010 @06:52PM (#34106720) Homepage

    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

    Does it also cause words in sentences to duplicate? Does it also cause sentences to duplicate? Also, was this submission done on an Android phone?

    • No, No... And well sort of, the submission was done using a series of LightBrights using the colours as different values in Hexadecimal, taken from a picture with an Android Phone - and then ran through an image processor to turn those light values into Hex. Then some open source Hex to String converter for the submission - so while the duplicate sentences might have been one of the other 271 bugs they found in the Android phone, there's a lot of other places this bug might have taken place.

  • Android or Linux (Score:5, Interesting)

    by MSG ( 12810 ) on Tuesday November 02, 2010 @06:53PM (#34106746)

    Apparently no word on whether these are flaws in the vanilla kernel which Google has inherited, or flaws in the code that Google wrote.

  • by SoupGuru ( 723634 ) on Tuesday November 02, 2010 @06:59PM (#34106818)
    Vulnerabilities are found and hopefully patched.

    As for Windows Phone 7, what we don't know won't hurt us, right?
  • 88 bugs... (Score:3, Funny)

    by MrEricSir ( 398214 ) on Tuesday November 02, 2010 @07:00PM (#34106830) Homepage

    ...about 44 women?

    • by geekoid ( 135745 )

      Android is an open System, open to the whole wide world.
      Window is a bitter pill, security is a joke,
      iOS is a controlling freak, locked down app to unfurl.
      Linux lays the code right out, guarded by bearded blokes.

    • Very nice "Nails" reference MrEricSir.

  • by Lead Butthead ( 321013 ) on Tuesday November 02, 2010 @07:00PM (#34106834) Journal

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

  • They are outed, and so get fixed even faster.

    Good luck with the iOS/Wimpy7s bugs that are never announced/found due to this type of peer-review, and so there's no priority to fix them.

    • by drcheap ( 1897540 ) on Tuesday November 02, 2010 @07:26PM (#34107044) Journal

      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.

      • by wrook ( 134116 )

        This is an issue I have with this kind of consumer electronics that use open source software as the base. They have to be able to let me patch my own device. Maybe not everyone can do it, but personally I don't want to wait for my phone company to push an update to me (which might be never). It's the reason I won't buy an Android device unless I can get root and can flash my own roms. If I can't do that it might as well be closed, proprietary software.

      • Re: (Score:3, Interesting)

        by jonwil ( 467024 )

        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.

      • by fermion ( 181285 )
        Really this should not be an issue. Any customization should be a relatively high level, and if the device manufactures are playing fair any low level fixes should be put back into the source tree. If kernel fixes are going to negatively impact Android as implemented on individual devices, this would lead credence to the idea that Android will eventually die due to fragmentation. If the community cannot self enforce a strict set of guidelines to insure low level fixes will not break the higher level cod
    • Whilst I do mostly agree...there's also a part of me that is trying to be realistic.

      The great thing about open source is that everyone has the code so bugs are found quicker.

      The not so great thing is trying to find someone to fix them.

      Then there's another layer of pain with android because if the manufacturers and carriers take 6 months to release an update, do you really think they'll fix these flaws? Google really should've stuck to the Windows model, requiring a standard android base so that updates cou

    • by bonch ( 38532 )

      [citation needed]

  • details? (Score:2, Insightful)

    by JustFisher ( 1123293 )
    Andoid revision? Which kernel version? What are those 88? Did they found kernel flaws or app platform in general? What are you/they talking about?
  • by gonar ( 78767 ) <sparkalicious@veri[ ].net ['zon' in gap]> on Tuesday November 02, 2010 @07:19PM (#34106990) Homepage

    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)

    • Re: (Score:2, Informative)

      If you had read TFA, you'd have seen that Coverity is not releasing any details until January to allow Google and vendors to fix things.
      • ...assuming they buy Coverity licenses. Which are very expensive. Nice sales tool to announce a 'secret' list of critical flaws to force Google and AnDev's to buy their software, while getting lots of free press.
        • by amorsen ( 7485 )

          I must admit to not RTFA, but usually Coverity provides the results for free to free software projects. I haven't heard of them holding anyone for ransom like that before, so I'm a bit sceptic of your claim.

          • They may supply the output for free as you say. But I would have to assume Google and other for-profit developers need to retest using a licensed copy. Or more to the point, I would assume that Coverity would assume that. Perhaps I am terminally cynical, but even if Android can be considered a free software project I dont believe Coverity is trying to help Google out of sheer altruism.

            OTOH you seem to have had positive experiences with them, so perhaps they deserve the benefit (I also automatically cave to
    • Coverity is really a code review tool. From your code, it tries to construct a model that shows your code is correct (static analysis + type inference). If it can't, the code is flagged, and it should be reviewed by a human. The flagged code may or may not be a bug, only that Coverity couldn't prove its correctness. If anything, I would advocate that the code should be rewritten in order to pass Coverity check, in the same spirit that if another competent person doesn't understand your code, you should prob

      • by EvanED ( 569694 ) <[moc.liamg] [ta] [denave]> on Tuesday November 02, 2010 @10:21PM (#34108048)

        However, I've not seen any formal soundness proof of Coverity itself. As a result, Coverity may very well accept buggy programs as correct. This would certainly limit the tool's usefulness.

        Oh, it definitely does. And in some sense it limits its utility, but it also is what lets it be as successful as it is.

        Rice's theorem says that the ultimate goal -- determine whether a program is buggy -- is literally impossible to be guaranteed to do completely accurately. Because of this, there are three possibilities that you can take when making a tool that attempts to do that; you must pick at least one.

        1. You can say a program is (or may be) buggy when it isn't.
        2. You can say a program is free of bugs when it is actually buggy.
        3. You can accept the possibility that your tool will run forever.

        Each of these occurs in practice. A familiar example of #1 is the type system of a statically-typed language: if x has type int and y has type SomeClass, the type system will say that a program containing the expression x = y is not legal even if it is impossible for that statement to actually execute (and thus the actual failure type systems are designed to prevent can't actually happen). I'm actually having a hard time thinking of a tool that picks just #2, but I'm sure there are some out there. #3 is the hallmark of some techniques such as concolic execution and some recent work on program verification. (I'm involved in one of the last tools.)

        But there are also a number of tools out there that admit the possibility of both false positives and false negatives: in other words both #1 and #2 can happen. The benefit you can get by doing that is that you can get an analysis that can find errors that are rather deeper than, say, your type system and yet it'll still scale to very large programs.

        There's no one perfect analysis; there's a spectrum based on how much you value finding bugs, how much you value gaining assurance that a program is bug-free, how deep of bugs you want to find, and how large of a code base you have to run on. Saying that Coverity "limits its usefulness" based on the spot it choose in the design space is true, but slightly misleadingly so, because every program analysis limits its utility, just in different ways. IMO not having used it, Coverity found a spot which is quite useful.

    • 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)

      But don't the carriers have a history of taking their sweet time before pushing updates down to consumers? Or is that just for major releases... hopefully they are more prompt with security updates.

    • Personally, I'm using Gimpel PCLint.

      It's a much more mature product than Coverity, and clearly less advertised !

  • by Anonymous Coward on Tuesday November 02, 2010 @07:23PM (#34107028)

    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.

  • []

    Fix it fix it fix it.

  • ...and I'm supposed to be complaining?
  • by Anonymous Coward on Tuesday November 02, 2010 @07:46PM (#34107196)

    If you're havin' 'droid problems i feel bad for you son,
    I got 88 problems but a bug ain't one

    • Re: (Score:3, Funny)

      by V!NCENT ( 1105021 )

      If you're having girl problems I feel bad for you son,
      I got 88 bugs but a bitch ain't one.

  • SERIOUS (Score:3, Informative)

    by SirThe ( 1927532 ) on Tuesday November 02, 2010 @07:48PM (#34107208)
    You could like mention that this is projected to be the least number of vulnerabilities per line of code they found. Oh wait, that would require reading the article.
  • That really pisses me off to know that Google or whoever is driving the Android development didn't hire some security testers to find this critical stuff before it was released.

    Fortunately, I believe the fixes will come out for me before the carriers get around to do. My Galaxy S is pretty good about being able to load new custom firmwares now. Feel bad for "regular" users who depend on updates from carriers.

  • by zuperduperman ( 1206922 ) on Tuesday November 02, 2010 @08:03PM (#34107316)

    In truth, this is a strength, not a weakness of Android - this is the "many eyes" of open source in action. No doubt the important fixes among these will be addressed pretty quickly.

    The problem, however, is with the carriers who keep insisting on pushing custom firmware on their devices. With many devices never receiving any updates at all they are wide open - how long until we have massive malware issues because of this?

    What I hope is that this drives some consumer backlash which forces the carriers to stop the nonsense with customizing the core of android and instead just put their skins on the topmost UI layer. They should realize quick smart that they are not and should never be in the OS business and that updates need to come out within weeks of releases from Google, not years or never.

    • Here here. I actually hope there is some sort of widespread malware or a virus just to push this issue. I really like android as a user and developer but I hate the carrier lockdown.
  • by SpazmodeusG ( 1334705 ) on Tuesday November 02, 2010 @08:10PM (#34107352)

    There's a function that helps avoid exploitation of the vulnerabilities in the API.

    Just ensure that it's returning false and you should be safe.

  • by danwiz ( 538108 ) on Tuesday November 02, 2010 @10:06PM (#34107968)

    Exposes more than, say, a very simple app (game?) that requires Full Network Access, Fine Grained Location, and access to your System Settings?

    The biggest threat to personal information leaking on an Android phone are overly permissive apps, and the people who install them.

  • In the world of O/S frameworks Android is pretty much still a toddler and it is trying to run like a 16 year old with a bright future in track so please don't act surprised, bugs happen. Although i gotta say a "use after Free" is pretty bush league.

  • How did Apple manage to get these faults into the phone in the first place? They must have spies deeper than we originally thought!
    For shame, to stoop to sabotage! Will Jobs stop at NOTHING?

  • I'm trying to figure out why someone would analyze the source code to an open project, find defects, and NOT fix and commit the defects for code review. I mean, that's how the process is supposed to work. Unless this is just a publicity stunt.

A committee takes root and grows, it flowers, wilts and dies, scattering the seed from which other committees will bloom. -- Parkinson