Please create an account to participate in the Slashdot moderation system


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 AuMatar ( 183847 ) on Tuesday November 02, 2010 @06:53PM (#34106744)

    Probably not many. Android has a rather large application framework running on top of Linux. The flaws are most likely in it, and most likely allow you to get access to data that you don't have permission to (permissions are implemented in the same code layer). When people talk about android, android isn't really an OS- it's more like Gnome or KDE with a basic permission system hacked on (and a totally Android only API).

  • by Anonymous Coward on Tuesday November 02, 2010 @06:57PM (#34106782)

    I don't know much about these platforms, but Android is based on Linux yes? SO would many of these vulns still be in Linux?

    No. Android is a Java-like virtual machine, some libraries implementing an API, a user interface and a standard set of user-level tools, all of which runs on top of a Linux kernel. The story refers to Android issues, not Linux issues.

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

    The only reason Android is selling more phones in the US is because they are on more carriers. Which is about to change. Android will take a big hit when that happens just as happened in Europe.

    Whoever the idiot is who thinks OS X uses Linux needs to get a clue. It's the mach Kernel, some BSD subsystems, Darwin, and a UI layer.

  • by cr_nucleus ( 518205 ) on Tuesday November 02, 2010 @07:17PM (#34106972)

    Apple wants to sell lots of expensive smartphones

    The device is only a mean to get people to pay for applications...

  • by Esospopenon ( 1838392 ) on Tuesday November 02, 2010 @07:39PM (#34107154)
    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.
  • 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.
  • by AndrewNeo ( 979708 ) on Tuesday November 02, 2010 @07:50PM (#34107222) Homepage

    Huh? Dalvik is a Java-like virtual machine. Android is the API, UI and user tools, running on top of Linux.

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

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

  • by Mr2001 ( 90979 ) on Tuesday November 02, 2010 @10:58PM (#34108226) Homepage Journal

    When people talk about android, android isn't really an OS- it's more like Gnome or KDE with a basic permission system hacked on (and a totally Android only API).

    Not quite - Android also includes a set of kernel patches [].

  • by amorsen ( 7485 ) <> on Wednesday November 03, 2010 @02:13AM (#34108828)

    It isn't astroturfing. No one is pretending to be from the "community" or "grass roots" or anything. It's plain marketing.

    Coverity provides free code checks to many free software projects, in exchange for being able to make press releases like this one. The mainline Linux kernel has been through it at least a few times, but Coverity seems a bit confused or unhappy about the fact that Linus won't discuss bugs in secret. Many other large free software projects have a group of people who are willing to sign NDA's when dealing with security bugs, so bugs can be patched before being announced.

  • Re:SERIOUS (Score:1, Informative)

    by Anonymous Coward on Wednesday November 03, 2010 @03:26AM (#34108966)

    Could you please cite where it says that? The only thing that even remotely looks like your claim is "While Android’s density of bugs per thousand lines of code was lower than the average found in open source software overall, it was higher than that of the Linux kernel" and that's not very close.

    The fact that a linux kernel version gets pretty good results at a coverity scan is not surprising as the kernel gets scanned fairly frequently.

  • by TheRaven64 ( 641858 ) on Wednesday November 03, 2010 @07:36AM (#34109666) Journal

    The general working definition of an OS is the stuff that you need to boot the system and launch programs.

    It is a struggle to see how the full OS X (or Windows) would not meet this definition.

    The full OS X includes a load of apps, such as iCal, Address Book, and a load of frameworks that are not needed to launch apps. It contains a load of stuff that is not required to boot the system. It is a superset of Darwin, just as Darwin is a superset of XNU (but XNU can not boot on its own, while Darwin can). Any Darwin program will run on OS X, but not every OS X program will run on Darwin, because it may use some of the Apple frameworks or applications.

    You have, however, demonstrated the one consistency I've seen with "technical people" when defining what an "OS" - they always go out of their way to ensure whatever set of rules they make up excludes any sort of "GUI" from being included

    Not at all. The Quartz GUI is a separate process, the WindowServer, which is launched after the init process runs. If you hold down option-S when booting a Mac, it is not loaded, but you can still run programs. If you log in as the >console user from the graphical login screen, the WindowServer exits and you can proceed without it. It is, therefore, a clearly optional part of the system. You can even exit it and run instead on an OS X system, although the from Apple runs on top of Quartz. There are other Darwin distributions which only include and not Quartz.

    In contrast, Windows has a closer integration and does not expose a terminal-emulator interface to programs, so you must load at least part of the GUI if you want to run programs (if you boot NT in the emergency recovery mode, you actually get the the GUI loading and then running cmd.exe in a command prompt window).

    You have to include a shell for most UNIX-like systems, because the init system runs shell scripts, and you could not finish system startup without it. You have to include libc, because that provides the programmers' interface to the kernel (the Single UNIX Specification only specifies C interfaces, not system calls). You have to include programs that are run by init scripts, such as ifconfig. You do not have to include X11, because the system will happily boot and run programs without it - you can even run graphical programs on a remote display without having X11 running locally.

  • by imakemusic ( 1164993 ) on Wednesday November 03, 2010 @08:22AM (#34109820)

    I mean after search, what have they delivered besides betas and hype? Collapsible threads in webmail?

    Google Maps
    Google Earth/Moon/Mars
    Google Skymaps
    Google Translate
    Google Docs
    Google Calendar
    Google Desktop Search
    Google Image Search
    Google Code
    Google Talk

    Plus they run/own:

    But apart from that, nothing...

    I'm not saying they're perfect but saying that they've done nothing but search is just plain wrong.

Nothing makes a person more productive than the last minute.