back to article Android kernel leaks like a colander

Security analysts at Coverity reckon the Android kernel is riddled with security holes, though they still rate it as twice as good as most open-source projects. Taking the source code from the HTC Incredible, Coverity found .47 defects per 1,000 lines of code, compared with an industry average of 1 per 1,000. That totalled 359 …

COMMENTS

This topic is closed for new posts.
  1. Anonymous Coward
    Grenade

    Well yes

    Android is based on Linux, no? So why would anyone be surprised that the code-base is a little ropey? Take a look at pretty much any linux source code and shudder at what you find. Not pretty...

    (and yes, I know there are exceptions, but on the whole...)

    1. Loyal Commenter Silver badge
      FAIL

      Really?

      Are you conflating the OS with the apps written for it?

      If you are looking at the source for the kernel, for instance, what are you comparing it against that makes you 'shudder'? I hear the Windows source code will make you go blind if you look at it for too long, but then it's closed, so that assertion can't be proved, can it?

      1. Anonymous Coward
        Anonymous Coward

        @Loyal commenter

        Windows may be closed, but you can get its source and the people I know who've seen it say its pretty good.

        Also, as far as I remember the code that was leaked a few years back was pretty good.

        Feel free to keep sticking it to MS in ways which you think will be unverifiable, though.

      2. Anonymous Coward
        Boffin

        The thing is....

        ...that just because there are bugs in the Linux kernel does not mean that they are exploitable because *nix OSs generally have greater privilege separation between the kernel and user processes. Windows is getting better in this regard, but is still more likely to allow high level privileges to be granted to users on request, after all that's what UAC does whereas in a *nix OS if you don't know the root password then you're not doing it.

        The very fact that this analysis has been done and that the Android devs are getting the results means that much of this will be cleaned up soon, which has to be good right?

      3. Giles Jones Gold badge

        Win2k

        There's people who looked at the stolen Windows 2000 code and said it's generally good.

        http://www.kuro5hin.org/story/2004/2/15/71552/7795

        Ignore all the comedy stuff at the top and look at the comments further down.

    2. Chemist

      "So why would anyone be surprised "

      I'm not surprised you're anonymous !

    3. DrXym

      @AC

      Open Source is no guarantee that code is of high quality, but the key point is that the code can be reviewed and it can be fixed by anyone. Who knows what bugs are lurking in some commercial operating systems because they don't disclose the source code so that it can be reviewed. Making code proprietary certainly doesn't appear to increase security as can be seen merely by reviewing all the critical flaws that have affected in closed source projects over the years.

    4. Jad
      Unhappy

      Linux ... Secure

      I've taken a look at the code for Linux.

      I've spent some time fidling with the SCSI code (anyone remember SCSI?)

      It's god damned awful.

      The main trouble was that it was basically passing data packets around in unsigned blobs of unknown size, even when it knew the size it was working with.

      Most of the code was fine and fit the standard SCSI definitions, but the latter half of the instructions seemed to change from supplier to supplier.

      The guy who wrote it originally had a scanner that used the SCSI code one way, so he hard-coded the _entire SCSI system_ to work with his scanner.

      It created the blob, and knew it's size, it passed the blob to another routine which unpacked it and put it in another blob, this routine then sent it to a completely separate routine which unpacked it and sent it to the SCSI device ... but the sizes all got messed up when they could just have been passed about, or placed in the blob before the data.

      the worst part is that my contribution looked for certain instructions that were passed in as part of the blob, and changed the assumed packet size for the 2 instructions that I needed changing, rather than fix the code properly.

      I love Linux, I'm not a windows user, but some of the code is bad.

      1. Homard
        Pint

        @Jad

        One question, did they guy that wrote that code have access to manufacturers data on the SCSI interface for it, or was it reverse engineered ?

        We are all learning and we do this by coding. Ever taken a look back at some of your earlier projects ? WTF was I doing :-) ???? Why did I do it that way ? You get the idea I'm sure !

        Beer, as in free :-)

        1. Jad

          @Homard

          "One question, did they guy that wrote that code have access to manufacturers data on the SCSI interface for it, or was it reverse engineered ?"

          I know that in my case, with the Canon SCSI Scanner I was using; I had signed the NDA to access their documents in order to modify the Linux kernel to access that specific scanner.

          I believe that previous guys/gals had had access to the specs of the devices they were using ... most of them were available online even at that stage, and the basic SCSI spec was very detailed since all manufacturers had to stick to the spec in order to call their device SCSI.

          " ... Ever taken a look back at some of your earlier projects ? "

          Actually I did ... I used to write in BBC Basic on an Acorn Electron (come on, someone must remember :) ) I wrote an adventure game just to test the concept ...

          I did a computing course at college and learnt loads of new techniques and flow techniques.

          I was stuck for a job for about 2 months after I finished so I thought, as you do, to go back and see if I could improve on this Adventure game, and fix broken loops (exiting out of uncomplete loops or using goto's, you know the type) and change the variable types to work better or more efficiently, proceduralise everything, etc.

          I looked back at the code, I spent ages examining it (well about a week, but the code wasn't huge ... I'd already stored the Data separate from the code.) ... I made about 1 change on one line in the code.

          Looking back at my old code that I write here, most of the changes are based on the fact that I update the comments to help my boss if he ever needs to look at it in future. Yes I've made other changes, but then I code mostly SQL now, they're usually due to database changes.

          I like Linux, it is inherently more secure than windows, and the code is getting better and it does look nicer than it did in 1999. I have to support Windows as part of my job, but I won't go back, you can't make me!

          1. Homard
            Pint

            Hey Jad !

            Fond memories of BBC basic !

            Ah those were the days, when computing was still in its 'frontier' days.

            Your code must be considerably better than mine (brummy accent please) as I find the odd 'screwup' when I go back to my code after a while :-) ! Yes it works as tested, but this different situation could be handled better :-).

            More beer please !!!!! Or is that the problem ? :-)

    5. Anton Ivanov
      Flame

      You obviously have not tried to read opensolaris code

      While I do not write in C myself, I have had to dive into the IP stack and other portions of the kernel on BSD, Linux and Solaris many times for a living.

      Linux will not win a beauty award (especially compared to BSD sources which are a pleasure to read). However most of its kernel code is not bad. Most of it is also understandable and can be analysed for security problems through simple code inspection.

      Try analysing anything through code inspection on Solaris kernel for laughs. For example its network stack can be undestood only with a BIG jug of something 80 proof and lots of aspirin at hand. Not that the rest of the kernel is much better either... Actually even ethanol solutions and aspirin are not a guarantee that you will grok what is going on. Example - on Solaris tcp is a 1MB+ _SINGLE_ C file with all offload, crypto, etc hooks crammed into that single file. Example on "How not to organise code" (TM). Analyse that? Some other time...

  2. Anonymous Coward
    Gates Horns

    Oh yes ?

    Was this study sponsored by Microsoft ?

    The usual media shenanigans me thinks.

  3. Thom Brown

    So....

    "Coverity found .47 defects per 1,000 lines of code, compared with an industry average of 1 per 1,000. "

    So it's less than half the industry average?

  4. Anonymous Coward
    Linux

    Great stuff

    Yes so closed source OSes like IOS from crapple have double the number of defects.

    1. The Other Steve

      Only not

      "Coverity has been testing code in open source projects since 2006. In fact, in 2010 we’ve analyzed over 291 projects and 61 million lines of code"

      Coverity don't explain in their post where they got that 'industry average' figure from, but the above suggests it is only for FOSS. Which would make sense, really, since they need the source code.

      1. Anonymous Coward
        Anonymous Coward

        Well, obviously...

        ...you just point your handy automated scanner at sourceforge.net, scan every project there and, surprise, surprise, discover that the vast majority of them are badly written. Voila, one "industry standard".

    2. Anonymous Coward
      Anonymous Coward

      iOS is closed source?

      Someone ought to tell them about http://opensource.apple.com/ then. Or perhaps penguinistas and fandroids should get their facts straight before mouthing off.

      1. Graham Dawson Silver badge

        A few libraries do not an open source OS make

        Unless you can believe that iOS is run entirely by a javascript engine and make. OSX is open source, they're quite good about that. Not perfect of course, a lot of it is still closed, but th meat of it is open. iOS?

        No.

        What was that about getting facts straight?

        1. Anonymous Coward
          Anonymous Coward

          Wrong!

          Since iOS is based on the same 'meat' as OS X (eg; Xnu, look under the 'OS X' heading). So in answer to your question;

          'Not perfect of course, a lot of it is still closed, but th meat of it is open. iOS?'

          Yes. As much as OS X is.

          Like I said Graham, check your facts first.

  5. Chris O'Shea
    Thumb Up

    Not just for open source ...

    Coverity and similar tools are used by many organisations (including mobile OS) to test their code. Being open source merely allows external people to run the same tools and get the same results ... but any complex system will have areas that are identified as "major" which, on further inspection, either are in code that can't be reached (particularly older code, you end up with DLLs etc. with routines that are not called because they are for, say, a driver tweak for a piece of hardware that is no longer used) or where the surrounding pre-conditions and error trapping will stop that piece of code ever actually causing an exploitable security hole.

    This means that Coverity could find 88 "major" errors, that, after inspection, many of them are not security holes and are adequately trapped or pre-conditioned so that the error code will not cause a user a problem.

    The good side of open source is that it means many people *can* check, and many people can submit fixes ... the potential bad side is that not all fixes are of the same quality, not all have been checked, and the bugs that are *real* problems may not be the ones that get fixed first. There are of course ways of handling this :-)

    So just a count of bugs is not necessarily a sign of good or bad design or programming (but ideally there should be very few if any!) but when you have a large code base, then it is often a matter of prioritising performance vs features vs defects ....

    047 sounds good to me, though it is not clear from this article whether 1 per 1000 lines of code is for mobile OS kernel, or for all apps in all programming languages on all platforms ... so as a statistic, it's rubbish! :-)

  6. Anonymous Coward
    Anonymous Coward

    Coverity

    Been trying it out for the first time today - quite an impressive piece of software. Finds lots of stuff that manual code reviewing and testing can miss. Can't figure out how to determine defects per 1000 yet, but will be interested to know what the figure is for our code base!

    (Disclaimer - not a Coverity employee!)

  7. The Other Steve
    Stop

    Again with SLOC metrics

    Meaningless. Bugs is bugs. Code analysis is great, but SLOC metrics suck ass.

  8. Anonymous Coward
    Anonymous Coward

    I was worried for a minute...

    ...when I read this statement:

    "Coverity found .47 defects per 1,000 lines of code, compared with an industry average of 1 per 1,000"

    But then I realised that, thanks to my screen resolution and lack of a leading 0, I had read the statement completely incorrectly. Phew...

  9. John G Imrie

    Methodology?

    I wonder how this works.

    There are places where you won't be checking pointers or array bounds or even for pointer arithmetic simply because you don't want to burden the code with the error checking at that level.

    You do your error / bounds checking at a higher level of your abstraction to keep the low level code fast.

  10. Ken Hagan Gold badge

    That industry average

    Is it for FOSS projects in general, or just OS kernels? How does Android compare with the Linux kernel that it was originally forked from? What's the rate of false positives from Coverity?

  11. Anonymous Coward
    Troll

    twice better than the average ain't that bad

    Given that products like OSX and Windows participate to said average, presumably.

  12. Graham Bartlett

    @John G Imrie

    Dunno about this one, but I've used other static checkers in the past. The good ones will work backwards until either they find something calling them with known data or until they find a public interface (where the data coming in could be anything). This does have the downside that if you have unreachable code then some bugs might not get exposed until you feed your code with data, but it avoids the situation you're talking about. The tool will generally report unreachable code anyway, and if the code can never get hit then bugs in it are a bit of a moot point.

  13. Anonymous Coward
    Jobs Horns

    How long

    before Steve Jobs uses this info to further brainwash their cult followers?

  14. ArmanX
    Alert

    "Riddled with holes"? "leaks like a colander"?

    "Security analysts at Coverity reckon the Android kernel is *riddled* with security holes, though they still rate it as *twice as good* as most open-source projects."

    Now, I may be wrong, but in industry, open source programs tend to be at least as reliable as closed source programs. Assuming the average open and closed source projects are roughly the same reliability, if the Android kernel is "twice as good as most open-source projects," then doesn't that mean that it is roughly twice as good as most closed-source projects? And thus, doesn't this mean that the average piece of software is only half as reliable?

    This article takes what seems to be a clear positive - Android OS has been tested and shown to have half as many security holes than the average open source project - and turns it into what seems to be an anti-Android "it's full of holes!" piece. Seems a bit fishy to me...

  15. shameek

    Hang on a minute

    Sorry have I misread the article? Android has less bugs than the industry standard (an average of what it doesnt say and quite useless statistic) but it leaks like a sieve. Shame on you register, I expect better from you, god know why. I'm all for bashing the big guns but c'mon!

  16. annodomini2
    Thumb Down

    Ooh how many flaws

    1. They don't list the version of the Android Kernel. Just that it was the one on the Incredible, no firmware version.

    2. No actual comparisons, just non-relevant statistics.

    A more interesting comparison would be with the linux kernel its based on and if these issues have been added by the Android Kernel developers.

This topic is closed for new posts.

Other stories you might like