Slashdot Mirror


Serious Security Bugs Found In Android Kernel

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

230 comments

  1. The most interesting thing about that article... by metrix007 · · Score: 0, Flamebait

    Is that Android now dominates the Smartphone market. Thank fuck. The less dominance Apple have with their fucked up control everything for you polices only a good thing.

    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?

    --
    If you ignore ACs because they are anonymous - you're an idiot.
  2. 88 critical flaws by Anonymous Coward · · Score: 5, Funny

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

    1. Re:88 critical flaws by icannotthinkofaname · · Score: 5, Funny

      You take one down, pass it around...

      ...89 critical flaws on the wall! ...shit, wait. My bad. These bugs are harder to fix than I thought they would be.

      --
      Let q be a radix > 1. I am in ur base-q, killing 10 d00ds.
    2. Re:88 critical flaws by blackraven14250 · · Score: 3, Funny

      There's more redundancy in the summary than there are flaws in Android kernel.

    3. Re:88 critical flaws by dkleinsc · · Score: 1

      If only bottles of beer worked that way. Maybe if I try and grab 255 at a time ...

      --
      I am officially gone from /. Long live http://www.soylentnews.com/
    4. Re:88 critical flaws by 4phun · · Score: 1

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

      Android: Coverity uncovered "a total of 359 bugs, about one-quarter of which were classified as high-risk".

      With Android in your pocket you ARE living on the edge!

    5. Re:88 critical flaws by NatasRevol · · Score: 0, Flamebait

      With Android, Google doesn't care about your personal information (again). Just ask Eric Schmidt. He'll tell you if you don't like it, don't use it.

      --
      There are two types of people in the world: Those who crave closure
    6. Re:88 critical flaws by LongearedBat · · Score: 1

      Chinese lucky number of critical flaws. Can anyone work out the feng-shui of that...?

    7. Re:88 critical flaws by camperslo · · Score: 2, 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...

    8. Re:88 critical flaws by TooMuchToDo · · Score: 4, Insightful

      Number of new bugs we know about in Android: 88. Number of new bugs we know about in Windows for the phone? Note the process at work.

    9. Re:88 critical flaws by totally+bogus+dude · · Score: 3, Insightful

      Well yes, they were found. How else would we be reading an article about them having been found if they hadn't been found?

    10. Re:88 critical flaws by JLennox · · Score: 1

      What you want to do is have 0 bottles of beer and drink one, soon you will have int.Max!

    11. Re:88 critical flaws by Johnny+O · · Score: 1

      Yeah but it says 88 flaws in the Android Kernel. Android runs the LINUX kernel.

      So there are 88 flaws in the Linux kernel?

      I know there are so many flaws in this statement, but cmon!?!

    12. Re:88 critical flaws by L4t3r4lu5 · · Score: 1

      It's a fork. The kernel is heavily modified. Check wikipedia for how it differs.

      --
      Finally had enough. Come see us over at https://soylentnews.org/
    13. Re:88 critical flaws by Stevecrox · · Score: 1

      Except I wouldn't be surprised if Microsoft ran Coverity as part of their build process. I am surprised Google don't.

      Where I work any project which is updated has a coverity run performed on it overnight. While Coverity isn't perfect and it can be confused it is a good bit of software.

    14. Re:88 critical flaws by Johnny+O · · Score: 1

      So when it was forked... There were 88 flaws...

    15. Re:88 critical flaws by DaVince21 · · Score: 1

      Sorry, Real Life uses 512-bit memory addresses.

      --
      I am not devoid of humor.
  3. Bug bounties? by Anonymous Coward · · Score: 1, Interesting

    How much are these worth in bug bounty money?

    1. Re:Bug bounties? by WrongSizeGlass · · Score: 3, Insightful

      How much are these worth in bug bounty money?

      To Google or to exploit writers? I'm sure they're both offering bounties but I don't think they pay the same.

    2. Re:Bug bounties? by Anonymous Coward · · Score: 0

      Obviously he means Google.

  4. Bounty by hellkyng · · Score: 1

    No wonder google didn't open up the security vulnerability bounty for Android...

  5. I'm so scared by Anonymous Coward · · Score: 0

    That's it then, I'm ditching my Android right now and getting a Winders SeVen pHone.

  6. Should have waited by Anonymous Coward · · Score: 1, Funny

    Should have waited and purchased a Windows 7 phone...

    1. Re:Should have waited by TheRaven64 · · Score: 4, Funny

      Windows 7 Phones have no security vulnerabilities at all. Not even attackers have worked out how to run code on them...

      --
      I am TheRaven on Soylent News
    2. Re:Should have waited by markdavis · · Score: 1

      ...because nobody has one or wants to have one :)

    3. Re:Should have waited by WrongSizeGlass · · Score: 1

      Should have waited and purchased a Windows 7 phone...

      I think you can pick up a Kin on eBay ... I don't think they're too worried about security issues.

    4. Re:Should have waited by Bill_the_Engineer · · Score: 2, Interesting

      Haven't you seen the commercial. Everyone with a Windows 7 phone have wrecked their cars trying to get it to work.

      --
      These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
    5. Re:Should have waited by jonwil · · Score: 1

      Give it a chance, I am sure people over at xda-developers are trying to figure out how to run code on the things as we speak (or if not, will begin doing so once the right people get hold of WP7 phones.

    6. Re:Should have waited by Tyger-ZA · · Score: 1

      True story: A friend broke his leg while trying to get WinMo 6.5 to work properly

  7. Ok... by al0ha · · Score: 0, Troll

    So what is the story, Tavis Ormandy exposes Windows bugs but does not work on top Google projects?

    --
    Did you ever wake up in the morning, with a Zombie Woof behind your eyes? -- FZ
    1. Re:Ok... by taviso · · 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).

      --
      ex$$
    2. Re:Ok... by Anonymous Coward · · Score: 0

      The Android Kernel is actually a lot different from Linux by now.

    3. Re:Ok... by Anonymous Coward · · Score: 0

      Travis Ormandy is my hero.

    4. Re:Ok... by Anonymous Coward · · Score: 0

      While true. I have noticed a different issue. There has been exactly 1 update since my phone came out and that was going from 2.1 to 2.2. There have been dozens of security updates such as this for when my phone source was made (back in mid june). Yet I have not seen *ANY* updates other than the major update. None.

      I have also not heard of any android phones getting any security updates (other than the rooted ones). Im thinking the manufactures of the phones have basically cranked them out and left them be. Putting 0 support into them. Maybe its not that big of a deal but these are internet connected devices...

    5. Re:Ok... by dudpixel · · Score: 1

      his point was that just because coverity finds bugs doesn't mean the bugs are automatically critical and representing actual useful security flaws.

      they _may_ be, but we'll need to wait for the full report to know...so this is just a 'hype' headline for now...you know...like we've seen every few days since android was first released.

      --
      This seemed like a reasonable sig at the time.
    6. Re:Ok... by Anonymous Coward · · Score: 0

      Just curious, did you fix and commit all those in under three days, or did you create and release public exploits for the same after 3 days?

    7. Re:Ok... by taviso · · Score: 4, 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.

      --
      ex$$
    8. Re:Ok... by Xest · · Score: 1

      No in this case it's just a study that's potentially flawed.

      They used automated code checking software, the problem is that this might flag some block of code as an exploit which would normally be if it weren't properly trapped. The problem with automated software like this is that it can flag things up that are correctly handled because it's smart enough to spot an exploit, but not smart enough to deal with the various different ways of handling potential exploits. It's also worth noting that classification of serious is quite arbitrary with this software, it could mean anything from "Really is serious", to "simply doesn't matter".

      Until someone has been through and manually checked each one (which is something Google may have already done using similar software meaning none of these are actual workable exploits) then the number of actual serious security bugs could be zero, 10, or 100- in other words the study basically tells us nothing, it's just an attempt to sell their software which is fine for finding potential security flaws, but useful by itself as a tool to guage how many security flaws truly exist in a piece of software.

    9. Re:Ok... by Anonymous Coward · · Score: 0

      Travis Ormandy is my hero.

      s/h/que/

    10. Re:Ok... by Chapter80 · · Score: 1

      Odd, I don't know why you're picking on me,

      Since I didn't recognize your name, and wondered why he might be picking on you, I Googled your name, and see why he might be picking on you. There are a lot of people out there who apparently think you are an asshole.

      I am reserving my opinion, but I'm just trying to help you understand (and inform others who may not have heard of you).

    11. Re:Ok... by bcmm · · Score: 1

      I assume "Android Kernel" is marketing-speak for "Linux"

      Android is not Linux. Since January, Google has been working on an increasingly incompatible fork of the Linux kernel.

      --
      # cat /dev/mem | strings | grep -i llama
      Damn, my RAM is full of llamas.
    12. Re:Ok... by AltairDusk · · Score: 1

      Blame your manufacturer, especially if they have their own overlay (Blur, TouchWiz, Sense). While they can't be expected to release a new update every single security fix they should be bundling them up and issuing them periodically.

  8. Does it also cause sentences to duplicate? by ruiner13 · · Score: 5, Funny

    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?

    --

    today is spelling optional day.

    1. Re:Does it also cause sentences to duplicate? by Monkeedude1212 · · Score: 1

      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.

  9. Re:The most interesting thing about that article.. by cinderellamanson · · Score: 0, Troll

    no probs man, if it's linux then it has MAC so no fucking worries man!

    --
    Hey buddy, can i bum a karma? ~}CinderellaManson{~
  10. *gasp* by bigspring · · Score: 1

    This number clearly differs from that of equivalent closed source systems! It's a shame that there's no current method for the community at large to help address these issues!

  11. Re:The most interesting thing about that article.. by AuMatar · · Score: 4, Informative

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

    --
    I still have more fans than freaks. WTF is wrong with you people?
  12. Android or Linux by MSG · · Score: 4, 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.

    1. Re:Android or Linux by Anonymous Coward · · Score: 0

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

      TFA specifically mentions that the Android kernel has more vulnerabilities than stock Linux kernels in general.

      So, it seems that either Android is not benefiting from upstream Linux kernel fixes, or Android kernel devs are introducing vulnerabilities. Either way, not good. Forking Linux has it's risks, this is a major one of them.

    2. Re:Android or Linux by wrook · · Score: 1

      Or flaws in the code that HTC wrote...

    3. Re:Android or Linux by kernhe · · Score: 1

      I knew Oracle's code is in there!!!

  13. Re:The most interesting thing about that article.. by Anonymous Coward · · Score: 1, Informative

    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.

  14. Re:The most interesting thing about that article.. by vakuona · · Score: 3, Insightful

    I don't think Apple was going for domination of the smartphone. Apple wants to sell lots of expensive smartphones, and they are not going to sell 100m of those year to year.

  15. score one for open source by SoupGuru · · Score: 2, Insightful

    Vulnerabilities are found and hopefully patched.

    As for Windows Phone 7, what we don't know won't hurt us, right?

    --
    What doesn't kill you only delays the inevitable
    1. Re:score one for open source by cyber-vandal · · Score: 3, Funny

      What we don't use surely?

    2. Re:score one for open source by Anonymous Coward · · Score: 0

      We don't know because it is a proprietary operating system from a company with a shaky security history.

      And don't call me Shirley!

    3. Re:score one for open source by gmhowell · · Score: 1

      Doesn't it remain to be seen if these patched versions are actually pushed to handsets?

      --
      Jesus was all right but his disciples were thick and ordinary. -John Lennon
    4. Re:score one for open source by pinkushun · · Score: 1

      Ignorance is bliss... until it happens to you.

    5. Re:score one for open source by AltairDusk · · Score: 1

      Why focus solely on WP7? The same could be said of iOS or Blackberry OS or any OS I'm forgetting which is closed-source.

    6. Re:score one for open source by delinear · · Score: 1

      I think he used WP7 as it comes from a company with a known history in this area and neatly highlights that closed source is certainly no guarantee of security (of course, we stand to be corrected if WP7 turns out to be incredibly secure). While the others no doubt also have their flaws, you mention Windows and you generally don't need to labour the point, people will see what you're getting at.

    7. Re:score one for open source by Anonymous Coward · · Score: 0

      And don't call me Shirley.

      Especially on that buggy Android.

    8. Re:score one for open source by cyber-vandal · · Score: 1

      I won't be using it until at least the first service pack.

  16. 88 bugs... by MrEricSir · · Score: 2, Funny

    ...about 44 women?

    --
    There's no -1 for "I don't get it."
    1. Re:88 bugs... by drcheap · · Score: 1

      Congratulations, you just showed your age with that song reference. ...crap, and so did I by replying.

    2. Re:88 bugs... by geekoid · · Score: 2

      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.
       

      --
      The Kruger Dunning explains most post on /. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
    3. Re:88 bugs... by zoid.com · · Score: 1

      Very nice "Nails" reference MrEricSir.

    4. Re:88 bugs... by zill · · Score: 1

      Linux lays the code right out, guarded by bearded blokes.

      Not just any bearded blokes, but bearded blokes with swords.

    5. Re:88 bugs... by Anonymous Coward · · Score: 0

      99 problems but a bitch ain't one.

    6. Re:88 bugs... by Anonymous Coward · · Score: 0

      According to Jay-Z, a bitch ain't one.

    7. Re:88 bugs... by Just+Some+Guy · · Score: 1

      Shame about the "flamebait". That was pretty funny. :-) My turn:

      webOS, a nichey thing
      that no one really understood.
      Kin, another Redmond product
      lacking any trace of good.

      --
      Dewey, what part of this looks like authorities should be involved?
  17. coverity's mindless drivel by Lead+Butthead · · 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."

    --
    ELOI, ELOI, LAMA SABACHTHANI!?
    1. Re:coverity's mindless drivel by drcheap · · Score: 1

      Exactly. Want to guess what percentage my internal bug tracking submissions at work that come in are initially tagged as "critical" before they are even confirmed?

      Hint: It's pretty close to the # that are marked "very low" after initial review :)

    2. Re:coverity's mindless drivel by mrawhimskell · · Score: 1

      "ELOI, ELOI, LAMA SABACHTANI"

      My God, my God, why has thou forsaken me - Jesus' words to God when He hung on Calvary's tree dying for the sins of the whole world. phew. twas worth it.

  18. this is a Success for open-source! by NuShrike · · Score: 1, Insightful

    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.

    1. Re:this is a Success for open-source! by drcheap · · 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.

    2. Re:this is a Success for open-source! by wrook · · Score: 1

      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.

    3. Re:this is a Success for open-source! by Anonymous Coward · · Score: 0

      Pffft, yeah right. Probably 99% of Android phones aren't even running (or even capable of running) the latest version of Android.

      Android is a weird thing. Because all the phone manufacturers have custom versions of it running on their phones you always get stuck with some old version and there is no way to upgrade until the manufacturer does a new release (which they generally never do, especially not major upgrades of the OS; often they have moved on to the next new phone and don't bother with upgrades for the old ones).

    4. Re:this is a Success for open-source! by Anonymous Coward · · Score: 0

      It's the reason I won't buy an Android device unless I can get root and can flash my own roms.

      I don't know why this comment is modded up as it's plain wrong. Sure, many consumers may not know (or want to know) about flashing their device but the process has been simplified time and again to make it more accessible to the userbase.

      You've been able to do exactly this since the first Android device. In fact, there is quite a large community of independent developers (who would have thought!?) producing their own custom ROMs for many different Android phones.

      Captcha: limited

    5. Re:this is a Success for open-source! by Anonymous Coward · · Score: 0

      There are plenty of Android devices that are locked down. Having to run some shady rooting application on it which voids the warranty is not really the same as the vendor supporting flashing the ROMs.

    6. Re:this is a Success for open-source! by Anonymous Coward · · Score: 0

      Also, what about those devices that the manufacturer refuses to put updated OS's out there for the users. I know of a few this year that are stuck on 1.5 and 1.6 that the provider refuses to update.

    7. Re:this is a Success for open-source! by jonwil · · Score: 2, 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.

    8. Re:this is a Success for open-source! by Anonymous Coward · · 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.

    9. Re:this is a Success for open-source! by dudpixel · · Score: 1

      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 could come directly from google, much like windows updates come from microsoft.

      --
      This seemed like a reasonable sig at the time.
    10. Re:this is a Success for open-source! by fermion · · Score: 1

      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 code, then there is no point.

      --
      "She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
    11. Re:this is a Success for open-source! by bonch · · Score: 1

      [citation needed]

    12. Re:this is a Success for open-source! by Anonymous Coward · · Score: 0

      With Android, yes. But I read his statement of "this kind of consumer electronics" as including also linux-based routers, set top boxes, coffee makers, et cetera.

    13. Re:this is a Success for open-source! by drcheap · · Score: 1

      Also, what about those devices that the manufacturer refuses to put updated OS's out there for the users. I know of a few this year that are stuck on 1.5 and 1.6 that the provider refuses to update.

      Well the good news is that this "serious security bug" is in 2.2 which means those users aren't affected (not that 1.5 & 1.6 are bug free).

      The other saving grace for them is that most carriers are offering "free" upgrades every 15-24 months, so if you have a device that is only 1.x compatible/supported, chances are it's close to EOL & replacement anyway.

    14. Re:this is a Success for open-source! by drcheap · · Score: 1

      Exactly. The past 5 or so phones I've had were plagued by bugs (not kernel security issues, but significant UI flaws, etc.) that were sometimes acknowledged and fixed by the manufacturer. But the only way to get that newer firmware was to buy a new phone that came from the factory with it, all because the carrier refused to provide an update mechanism.

      Like you said, this is one thing Apple did totally right.

  19. Re:The most interesting thing about that article.. by dimeglio · · Score: 1

    It will be soon time to upgrade. What do you think iPhone users will upgrade to? Apple just needs to stay slightly ahead of Android, Phone 7 and others, then throw-in some "wow" factor in order to keep selling millions of smartphones.

    --
    Views expressed do not necessarily reflect those of the author.
  20. Re:The most interesting thing about that article.. by Anonymous Coward · · Score: 2, Informative

    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.

  21. details? by JustFisher · · Score: 2, Insightful

    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?

    1. Re:details? by ZosX · · Score: 1

      They studied froyo. RTFA already.

    2. Re:details? by SirThe · · Score: 1

      2.6.32

  22. Re:The most interesting thing about that article.. by metrix007 · · Score: 1

    I understand you don't have a great understanding of security practicies, so let me enlighten you. MAC is great as an additional layer of protection and enforce least privilege. That doesn't mean we should ignore security vulnerabilities. Got it? Great.

    --
    If you ignore ACs because they are anonymous - you're an idiot.
  23. Re:The most interesting thing about that article.. by metrix007 · · Score: 1

    No one said anything about OS X using Linux, that I can see.

    --
    If you ignore ACs because they are anonymous - you're an idiot.
  24. Re:The most interesting thing about that article.. by cr_nucleus · · Score: 2, Informative

    Apple wants to sell lots of expensive smartphones

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

  25. Re:Is it just me? by Anonymous Coward · · Score: 0

    Actually, since this is open source - the people finding the bugs should have fixed them and posted the changes to the repository. Since they didn't do that, they must not care about the FLOSS community. For shame.

  26. coverity is a great tool. by gonar · · Score: 4, 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)

    --
    The difference between Theory and Practice is greater in Practice than in Theory.
    1. Re:coverity is a great tool. by Esospopenon · · 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.

    2. Re:coverity is a great tool. by Anonymous Coward · · Score: 0

      we use it at .

      Is that like Slashdot without the slash?

    3. Re:coverity is a great tool. by RenderSeven · · Score: 1

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

    4. Re:coverity is a great tool. by elashish14 · · Score: 1

      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.

      --
      I have left slashdot and am now on Soylent News. FUCK YOU DICE.
    5. Re:coverity is a great tool. by amorsen · · Score: 1

      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.

      --
      Finally! A year of moderation! Ready for 2019?
    6. Re:coverity is a great tool. by RenderSeven · · Score: 2

      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 any user ID under 10000 :-))

    7. Re:coverity is a great tool. by eulernet · · Score: 1

      Personally, I'm using Gimpel PCLint.

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

    8. Re:coverity is a great tool. by Anonymous Coward · · Score: 0

      Not altruism, for press value. Not just /. posts but engineers saying "wow this is useful". Yes it's greedy and self-serving, but they're thinking longer term and bigger scale.

    9. Re:coverity is a great tool. by jeffmeden · · Score: 1

      In case you are new to Android: the notion that the bugs are "fixed" in the Android source is one thing, the notion that they are "fixed" in a ROM available for a particular handset is *another* thing, and thinking that the fixes will make their way with *any* speed at all to the official carrier software for an android phone that stands a partial chance at making it onto a majority of the handsets is basically like waiting for Duke Nukem Forever to be released.

    10. Re:coverity is a great tool. by delinear · · Score: 1

      I have to say, I don't think Google will necessarily be too worried about the licensing cost. Other smaller companies who hear about the software via this story (and let's face it, that's the bottom line - they want to be the company that unearths a bunch of bugs in the Next Big Thing (tm) and sell copies of their own software off the back of it) can always choose to find their own bugs if they don't want to pay. It's a useful tool, that's all, for most developers it's not lack of ability to find and fix bugs that's the problem, it's that nobody wants to dedicate the developer resource to doing it.

  27. Re:Coverity uncovered a total of 359 bugs, but... by WrongSizeGlass · · Score: 2, Funny

    There's an app for that ;-)

  28. High False Positive Rate by Anonymous Coward · · 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.

    1. Re:High False Positive Rate by Anonymous Coward · · Score: 0

      I know less than half of you half as well as I should like, and like less than half of you half as well as you deserve.

      Redundant? Didn't check... It was too tempting.

  29. Re:The most interesting thing about that article.. by cinderellamanson · · Score: 0, Troll

    you mean it would have been better if the 88 bugs hadn't been there in the first place, even with MAC as implemented by the GOOG?

    --
    Hey buddy, can i bum a karma? ~}CinderellaManson{~
  30. Re:The most interesting thing about that article.. by dragonturtle69 · · Score: 2, 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/

    --
    "What luck for the rulers that men do not think." - Adolph Hitler
  31. Re:The most interesting thing about that article.. by mweather · · Score: 0, Redundant

    Darwin IS the mach kernel, Mr. Redundant.

  32. Re:The most interesting thing about that article.. by Dhalka226 · · Score: 2, Funny

    hey are not going to sell 100m of those year to year.

    Why not? This year's model is EVEN MORE SHINY!!!

  33. Re:The most interesting thing about that article.. by metrix007 · · Score: 1

    I should have known from your original response you were just a troll.

    --
    If you ignore ACs because they are anonymous - you're an idiot.
  34. ob. Futurama by geekoid · · Score: 1
    --
    The Kruger Dunning explains most post on /. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
  35. 88 ways to root your phone... by Dwonis · · Score: 1

    ...and I'm supposed to be complaining?

  36. 88 problems? by Anonymous Coward · · Score: 4, Funny

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

    1. Re:88 problems? by V!NCENT · · Score: 2, Funny

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

      --
      Here be signatures
  37. Re:The most interesting thing about that article.. by Anonymous Coward · · Score: 0

    Give him a break. He could just be clueless.

  38. SERIOUS by SirThe · · Score: 3, Informative

    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.

    1. Re:SERIOUS by Anonymous Coward · · Score: 1, Informative

      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.

  39. Where's the accompanying article by Anonymous Coward · · Score: 0

    'Serious security flaws most likely exist in iOS and Windows Phone 7, but we'll never know'

  40. Re:The most interesting thing about that article.. by AndrewNeo · · Score: 2, Informative

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

  41. And the carriers are too slow to respond... by erroneus · · Score: 1

    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.

  42. ha! who is living in a walled garden now!? by Anonymous Coward · · Score: 0

    Oh the sweet irony. You android lovers aren't talking now.

  43. Re:Is it just me? by V!NCENT · · Score: 3, 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...

    --
    Here be signatures
  44. coverity is a code review tool by pikine · · Score: 1

    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 probably rewrite it to make it more clear.

    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.

    --
    I once had a signature.
    1. Re:coverity is a code review tool by EvanED · · Score: 4, Informative

      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.

    2. Re:coverity is a code review tool by pikine · · Score: 1

      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.

      Actually, (1) characterizes tools like Coverity. I've also run into cases where a Hindley-Milner styled type inference needs a type annotation hint, or it wouldn't infer a type for my program.

      (2) characterizes almost every language where the type system is not expressive enough. For example, the type of the fgets() function in C doesn't establish any relationship between the char *s and int n. I could write this code:

      int main() {
      char buf[80];
      fgets(buf, 1000, stdin);
      }

      And the C compiler will accept as correct, but my program is buggy. It is more obvious for dynamically typed languages like Python or Javascript, where the program runs despite latent type errors in the program.

      As for (3), I vaguely remember a passing fact that type inference for impredicative polymorphism is undecidable. Maybe that's something you're working on? I'd like to hear about it.

      --
      I once had a signature.
    3. Re:coverity is a code review tool by EvanED · · Score: 1

      Actually, (1) characterizes tools like Coverity.

      Coverity can make (1) and (2), even for the bugs it finds. E.g. it can both say "this is a possible null-pointer dereference" when there can be no null-pointer dereference as well as "I did not find any null-pointer dereferences" in a program with null-pointer dereferences.

      (2) characterizes almost every language where the type system is not expressive enough.

      Fair enough; you can certainly argue that type systems are also (1) and (2); there's definitely some (1) for the reason I give.

      I tend to see buffer overruns as a separate class of bugs than the sort of things that type systems tend to prevent (treating this block of bytes as a floating point when it's an int), and thus don't really count that as a "missed bug" for the purposes of classification. (There's no analysis out there that even remotely claims to be able to find all bugs, so all tools have at least some (2) in them. So I rate tools in terms of the bugs that they claim to be able to find so that the category is actually meaningful.)

      As for (3), I vaguely remember a passing fact that type inference for impredicative polymorphism is undecidable. Maybe that's something you're working on? I'd like to hear about it.

      Nah; it doesn't really have to do with type theory at all. So one of the things I mentioned was concolic execution. This is a portmanteau of "concrete" and "symbolic" execution. It was originally conceived as a way of generating a set of tests for a function, aiming for high path coverage. Basically the way it works is you execute the function with some random input. You collect up a formula that describes the path that the trace took through the function (e.g. if the input is 'x' and it executed 'x=x+1' then 'if(x>0)' you'd get a formula like 'x_0+1 > 0'). You then negate the part of the formula corresponding to one of the conditions and give it to a theorem prover; if it's satisfiable, then what you get back is a new input for the function that will cause execution to take almost the same path, except take the opposite branch at the condition that you negated. That's your second test. Collect up constraints, feed it to a theorem prover, get the result, that's your third test. Repeat. (The "concrete execution" is running the function with the inputs you get from the theorem prover; the "symbolic execution" is building up the path constraint formula.)

      If the formula you give to the theorem prover is not satisfiable, then you have to discard it and try another. At some point, it's possible that you have tried all possible modifications of the formulas you've collected; if this occurs, congratulations, you now have a set of tests that gives you complete path coverage of the function. But if the function has a loop in it, then theoretically this will run forever, because you'll get tests that traverse the loop once, then twice, then thrice, etc. and you'll just keep increasing the number of times you go around the loop.

      Concolic execution gives you an underapproximation of the program's behavior: you get a bunch of concrete test inputs, but it's in general possible that they don't explore all of the function's behavior. You can't do program verification with an underapproxmation, because to say a program is free of bugs, you have to know something about all possible behaviors.

      Given this background, the recent work on verification I mentioned can be said to combine concolic execution with an overapproximation of the program. In this scheme, the overapproximation helps you discover new tests (in other words, get a more precise underapproximation) and the underapproximation helps you refine the overapproximation so it is more precise. In a nutshell, in cases where the theorem prover says a path constraint is unsatisfiable, instead of just tossing it out and trying another, you use that opportunity to make your underapproximation more precise.

      (The technique was originally developed at MS Research and at some point might replace the current engine in their Static Driver Verifier; the research group I'm in has adapted the idea and developed some new techniques that makes it amenable to verifying machine code instead of source.)

    4. Re:coverity is a code review tool by pikine · · Score: 1

      I tend to see buffer overruns as a separate class of bugs than the sort of things that type systems tend to prevent (treating this block of bytes as a floating point when it's an int)

      Buffer overrun happens when you are supposed to treat a block of bytes as void, hence you're not supposed to dereference the pointer, but you try to use it as char or int or float.

      You collect up a formula that describes the path that the trace took through the function (e.g. if the input is 'x' and it executed 'x=x+1' then 'if(x>0)' you'd get a formula like 'x_0+1 > 0'). You then negate the part of the formula corresponding to one of the conditions and give it to a theorem prover ... The technique was originally developed at MS Research and at some point might replace the current engine in their Static Driver Verifier

      How does linear constraint with no elementary recursion help verifying device driver code? How do I know if I'm programming hardware in an inconsistent state? How do I know if my program is having race condition with the hardware, say sending commands to the hardware when the hardware is not ready?

      --
      I once had a signature.
    5. Re:coverity is a code review tool by EvanED · · Score: 1

      Buffer overrun happens when you are supposed to treat a block of bytes as void, hence you're not supposed to dereference the pointer, but you try to use it as char or int or float.

      I know what you're saying, and lots of people call that sort of thing a type error. That said, to me it still feels very different than the 'x=y' case. One reason I think I feel that way is that you don't necessarily have to have a type error per se for something like that to cause a big bug. If you have in int array adjacent to an int, and you overflow the int array into the int, that's still a bug even though all the accesses are still consistent with the way the memory block is being used. Still, it's mostly a matter of perception.

      How does linear constraint with no elementary recursion help verifying device driver code? How do I know if I'm programming hardware in an inconsistent state? How do I know if my program is having race condition with the hardware, say sending commands to the hardware when the hardware is not ready?

      So the SDV works with a slightly different technique; assuming my memory is right, from the outside it actually looks pretty similar to my understanding of what Coverity does (and definitely Engler's Stanford Checker), so if you're familiar with that, you can skip the next paragraph.

      In addition to the program you're testing, you give it a specification of a property that you want to check. This specification takes the form of a finite state machine, where the nodes are specific to the property you're interested in and the transitions are patterns in the source code the tool looks for. The sort of canonical example I use is checking for correct lock behavior. Suppose you want to check that a function (including those it transitively calls) behaves properly with respect to a lock: it always exits with the lock released and never tries to lock it twice. Your specification will have three states: unlocked, locked, and error. The pattern 'lock(x)' moves the machine from the unlocked state to the locked state, or the locked state to the error state (double lock). The pattern 'unlock(x)' moves the machine from the locked state to the unlocked state, or the unlocked state to the error state (double unlock). Finally, the return of the top-level function will move the machine from the locked state to the error state (return with the lock held). (Coverity, and I think SDV, will instantiate different copies of the machine for different lock variables, so if you have 'lock(x)' then 'lock(y)', this is OK.)

      It's not too hard to adapt the techniques I discussed above to check a property specified in a similar manner. The techniques I described in my last post, in particular the verification work, can establish (well, given sufficient patience which may not happen) whether or not a particular program point is reachable. I'm not terribly familiar with the details of how the state-machine style checking, and there are probably a couple different ways to do it, but it basically consists of weaving the state machine code into the program code. Once that's done, you can check whether the code corresponding to the error state is reachable using the techniques above.

    6. Re:coverity is a code review tool by EvanED · · Score: 1

      ...so if you're familiar with that, you can skip the next paragraph.

      Um actually looking over my post, I should probably retract that statement; I'm thinking I probably didn't write the last paragraph in a way that makes much sense without at least getting the setting right. So you may want to skim over the second paragraph if you're familiar with Coverity instead of skipping it entirely. :-)

    7. Re:coverity is a code review tool by Ciph3rzer0 · · Score: 0

      2. You can say a program is free of bugs when it is actually buggy.

      Javascript?

  45. Real Problem is Slow Carrier Updates by zuperduperman · · Score: 4, Informative

    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.

    1. Re:Real Problem is Slow Carrier Updates by witherstaff · · Score: 1

      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.

    2. Re:Real Problem is Slow Carrier Updates by LordAzuzu · · Score: 1

      <quote><p>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?</p></quote>

      And obviously the users will say it's Google's (Android's) fault.

    3. Re:Real Problem is Slow Carrier Updates by Anonymous Coward · · Score: 0

      Or just get a iPhone which gets updated for flaws and has a easy delivery method for the fixes which means most users actually get patched.

  46. bounties? it's like tower defense game by whiteboy86 · · Score: 1

    Too many easy to zap bugs in this wave, just wait for next wave of bugs then make $$ defense upgrades.

  47. Most of these aren't really going to be an issue by SpazmodeusG · · Score: 2, 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.

  48. Re:The most interesting thing about that article.. by the_humeister · · Score: 1

    I don't see how Android isn't an OS. Sure, it runs on top of the Linux kernel, but that's like saying Mac OS X isn't really an OS because it's just a window/desktop manager and accompanying API running on top of the XNU kernel (and theoretically, Apple could have forked their own Linux kernel and used that instead of XNU).

  49. Re:The most interesting thing about that article.. by the_humeister · · Score: 1

    XNU is the kernel. Darwin is the subsystem without the UI layer. It's almost akin to a Debian base installation.

  50. Re:The most interesting thing about that article.. by AuMatar · · Score: 4, 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.

    --
    I still have more fans than freaks. WTF is wrong with you people?
  51. Re:Most of these aren't really going to be an issu by Dewin · · Score: 1

    Note that the user being a monkey might be a sort of exception that should never happen. A definite WTF moment, for sure.

    --
    Of course nobody reads the FAQ! If people read the FAQ, the Questions wouldn't be so Frequently Asked.
  52. Re:The most interesting thing about that article.. by Savage-Rabbit · · Score: 1

    It will be soon time to upgrade. What do you think iPhone users will upgrade to? Apple just needs to stay slightly ahead of Android, Phone 7 and others, then throw-in some "wow" factor in order to keep selling millions of smartphones.

    If they really go ahead, turn the Mac into a glorified iPod and turn OS X into a Java free zone I can tell you right now that I'll be upgrading to Ubuntu on my Mac. I'll have no choice since I do a lot of java development. I won't like switching very much but Linux is a damn sight better than Windows 7. Additionally, since Linux is an iTunes free zone I'll probably upgrade to an Android cell-phone.

    --
    Only to idiots, are orders laws.
    -- Henning von Tresckow
  53. bug in Androids by Anonymous Coward · · Score: 0

    It must be Microsoft's fault or Obama's since every other problem in the world is caused by them.. right... not..

  54. Re:The most interesting thing about that article.. by metrix007 · · Score: 1

    See, you are a troll. Your argument in the OBSD post was simple zealotism without understanding what you are saying, as evidenced by your lack of a reply. Then you couldn't let go and troll with the same shit in a completely different thread. Funny :)

    --
    If you ignore ACs because they are anonymous - you're an idiot.
  55. Re:The most interesting thing about that article.. by cinderellamanson · · Score: 0, Offtopic

    Offtopic sorry. I will repost shortly back in the thread and you are not exactly full of shit.

    --
    Hey buddy, can i bum a karma? ~}CinderellaManson{~
  56. Re:The most interesting thing about that article.. by exomondo · · Score: 3, Insightful

    Probably not many.

    Well 88 were found in the kernel, which is a linux kernel. But who knows how many of those are in the actual linux kernel mainline.

  57. Re:The most interesting thing about that article.. by the_humeister · · Score: 1

    Who exactly are these "technical people" you speak of? I know of no technical person who refers to Mac OS X as XNU. I know of no technical person who refers to Windows 7 as whatever the Windows 7 kernel is called.

  58. Who cares about it when no updates available! by Anonymous Coward · · Score: 0

    I bought a Motorola Milestone with Android 2.1 on it. Now, some basic features are not there or simply not working like the VPN for example. So I want to update to Android 2.2 but Motorola is too lazy and they lock down the phone if you try to update yourself.
    When I read the comments on the Market, I see that the Galaxy S has a lot of problem with compatibilities with apps...

    So how I'm supposed to think about the security issues now? I can't update and when I buy a phone, I can't be sure of anything... (updatability, compatibility, quality of touch screen, ...)

    If I buy a second phone, I will reach the price of a iPhone... why I didn't buy a iPhone at first? because it was twice the price...
    Now, from what I see, half-price = half-quality, half-secure, twice-headache!

    I'm really sorry, but I don't see how Android gonna be a good alternative to the iOS... Android is too young and doesn't grow up without buying a new phone...

    1. Re:Who cares about it when no updates available! by ZosX · · Score: 2, Insightful

      Yeah, because IOS is so much more secure than Android. New phones are churning out every 6 months. If you want to be ahead that's the price you have to pay. A new iphone is released every year. I don't really see what you are bitching about. If upgrading your firmware to the latest and shiniest is so damned important, buy a phone that isn't locked down, like a galaxy s or nexus one or htc desire or etc, etc, etc and install from the multitudes of roms floating out there. My "ancient" G1 is running froyo right now, and while it may not be the snappiest, I haven't had too many issues asides from the lack of ram on the g1 and a random reboot every few days due to using swap and a somewhat flaky microsd card.

      Really, even my lowly G1 is a million light years ahead of the crappy motorola candybar I replaced it with. This whole security issue is being blown way out of proportion. I would say that android by its own nature is fairly secure, seeing as how most everything runs in a sandbox anyways. If an app elevates permissions it should notify you and ask for your permission. Also it does say what each app has access to when you install. I don't really see what you could exploit here, since its a virtual machine running on top of a linux kernel. Yeah, you could exploit the kernel, but that wouldn't give you access to the VM running on top. Yeah you could get at the dalvik machine and probably execute overflows and whatnot, but there seems to be a good deal of internal checks against that sort of thing. IOS on the other hand runs everything natively. I would be willing to bet that IOS is easier to exploit than Android.

    2. Re:Who cares about it when no updates available! by delinear · · Score: 1

      The carriers and hardware manufacturers are still far too used to doing things the old way (perhaps one update during the life cycle of a phone, if you're lucky). However, what I'm starting to see are more and more complaints from regular (i.e. non-technical) users about the lack of updates. This is a good thing, eventually someone on the hardware side will start to capitalise on this by offering phones with minimal or no cruft on top of the base Android OS, and carriers who want to be able to offer all the latest updates will hopefully start to pick them up and release them without modification (and if not, there are plenty of places that will sell you a phone and a contract without the proprietary crap associated with that contract's carrier). What we should hope for is more updates from Android pushing flashier new features to drive public opinion in the direction of demanding the hardware/carrier side of things give us the ability to update over the air ourselves, out of the box.

  59. Re:The most interesting thing about that article.. by worx101 · · Score: 0, Offtopic

    Then you must really hate Oracle

  60. Re:The most interesting thing about that article.. by Anonymous Coward · · Score: 0

    no it really was irony. - "And I think your full of shit." was humor. :D

    I'm really sorry the Mac zealots modded you troll, that was unfortunate, but both funny and ironic.

  61. Re:The most interesting thing about that article.. by metrix007 · · Score: 1

    You know Mac != MAC right?

    --
    If you ignore ACs because they are anonymous - you're an idiot.
  62. Re:The most interesting thing about that article.. by cinderellamanson · · Score: 1

    it's punny.

    --
    Hey buddy, can i bum a karma? ~}CinderellaManson{~
  63. expose users' personal information by danwiz · · Score: 3, Insightful

    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.

  64. Re:Serious first post by poetmatt · · Score: 1

    wait, so you assume google is the only folks with a flaw?

    wow.

    I'm not saying google is infallible, but neither is, well, every company that exists. I dont' even need to mention names on that.

  65. Re:The most interesting thing about that article.. by Mr2001 · · Score: 2, Informative

    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.

    --
    Visual IRC: Fast. Powerful. Free.
  66. Re:Serious first post by Jeremiah+Cornelius · · Score: 1

    I don't claim that.

    But these BrotherPluckers start with a known Linux sourcecode base, fork it, and introduce this number of exploits in ring-0?

    They suck.

    --
    "Flyin' in just a sweet place,
    Never been known to fail..."
  67. Re:The most interesting thing about that article.. by bonch · · Score: 0, Troll

    It "dominates" in the same way Windows dominates PCs...a fractured mess controlled by the carriers, with their own unremovable junkware, their own app stores, and their own differing hardware features.

    Here's an article you won't see written about the iPhone: How Can I Tell If An Android App Is Malware?

    Personally, I'm not too excited about the idea of Google owning search, advertising, email, chat, documents, phones, netbooks, blogs, etc., all while skirting the edge of privacy. I'm not really interested in replacing one Micorosft with another. Apple is more concerned with being the best in a market, not #1 in a market.

  68. Re:The most interesting thing about that article.. by bonch · · Score: 1

    Since Android hit the market, there has been a lot of uninformed, suspicious Apple-bashing on Slashdot, often from anonymous posters.

  69. Lets face facts... by FlyingGuy · · Score: 1

    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.

    --
    Hey KID! Yeah you, get the fuck off my lawn!
    1. Re:Lets face facts... by Anonymous Coward · · Score: 0

      I think the only noteworthy part of this is that Coverity found that the average bug per line of code was half that typically found in other software.

      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 defects, with 88 of those being high-risk items such as memory corruption, memory leaks and uninitialised variables. Buut Coverity won't be providing any details until the end of the year.

      It's the /. summary that reports an absolute number of bugs without any context.

      http://www.theregister.co.uk/2010/11/02/android_security/

  70. Re:The most interesting thing about that article.. by msuarezalvarez · · Score: 1

    How much did you pay for the user ID?

  71. 88.... by froggymana · · Score: 1

    Can you go back in time now with the flux capacitor app?

    --
    "To prevent this day from getting any worse, I'll just read ERROR as GOOD THING" 1GJU8xLuDKDxEs4KLf8fAGyptoDsqvEsBT
  72. Re:The most interesting thing about that article.. by digitalchinky · · Score: 2, Insightful

    From the article and summary my own conclusion is that this is somewhat of an astroturf for Coverity and more than likely lacks any solid foundation. Certainly there may be bugs, but many are probably of the "Meh" kind.

  73. Re:The most interesting thing about that article.. by exomondo · · Score: 1

    From the article and summary my own conclusion is that this is somewhat of an astroturf for Coverity and more than likely lacks any solid foundation. Certainly there may be bugs, but many are probably of the "Meh" kind.

    I totally agree, the fact that they are announcing 'we found all these security bugs but we aren't going to tell you about them until google has a chance to fix them' rather than just speaking directly to google about them stinks of astroturfing.

  74. Re:The most interesting thing about that article.. by Dever · · Score: 2, Funny

    now now, give him time...it'll take a while for the cryogenic suspension effects to wear off...

    --
    - I'd prefer not to.
  75. Of course, the most important question is... by Suzuran · · Score: 1

    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?

  76. they need help? by sonixau · · Score: 1

    maybe google needs to reach their hand out to the greater community, as they can't do it all, but who can these days?

  77. Re:Serious first post by ooshna · · Score: 3, Funny

    This is Google, you know: a privacy flaw exposed in the kernel of their device isn't a FLAW! It's a business-enabling FEATURE..

    God damn Google for stealing Apple's business practices.

  78. If they found bugs, why not commit the fixes? by n2rjt · · Score: 1

    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.

  79. Re:The most interesting thing about that article.. by amorsen · · Score: 2, Informative

    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.

    --
    Finally! A year of moderation! Ready for 2019?
  80. Re:The most interesting thing about that article.. by amorsen · · Score: 1

    Why not? They're selling lots and lots of iPods, why wouldn't they eventually include phone functionality with lower-end iPods?

    --
    Finally! A year of moderation! Ready for 2019?
  81. Re:Serious first post by darkvad0r · · Score: 1

    Obligatory Monty python reference: http://www.youtube.com/watch?v=hSELOCMmw4A

  82. Re:The most interesting thing about that article.. by hhw · · Score: 1

    An OS consists of not only the kernel, but also the userland. You need to be able to interface with the kernel at least at some level. Just because GNU/Linux's userland is indistinguishable from third party applications doesn't mean that all operating systems are complete with kernels alone.

    --
    http://astutehosting.com/
  83. Re:The most interesting thing about that article.. by Anonymous Coward · · Score: 0

    So then that could be said about Apple too and their OS X with the BSD kernel.

  84. Re:The most interesting thing about that article.. by TheRaven64 · · Score: 3, Insightful

    A lot of people - myself included - refer to Darwin when talking about the OS, and Mac OS X when talking about all of the stuff that Apple bundles on the install CD (including Quartz, Cocoa, and so on).

    Defining the OS as the kernel is problematic when you have microkernels, because the line between what is the kernel and what is userspace is blurred. With Symbian, for example, device drivers live in the kernel but they don't handle multiplexing between applications. When an application wants to access a hardware resource, it talks to a userspace server. Are these servers part of the OS?

    The general working definition of an OS is the stuff that you need to boot the system and launch programs. With a UNIX-like system, this includes the init system (typically including a POSIX-compatible shell), and a set of libraries. Most importantly, it includes libc, because this is the public interface to the kernel's functionality. If you select a target when cross-compiling stuff for OS X, you select the Darwin target, not the OS X or XNU target (there isn't one), because the compiler needs to know things like the object format to use (Mach-O), the calling conventions (not defined by the kernel), and a few other things.

    This is why people talk about GNU/Linux as a platform; because it's GNU libc, the GNU shell, and so on that their programs interact with. You can swap out the Linux kernel for something like a FreeBSD kernel much more easily than you can swap out the GNU stuff for BSD equivalents.

    Some people use a slightly broader definition for UNIX-like systems, including everything needed for compliance with the Single UNIX Specification. Since this includes things like c99, c++, and vi, I think it's a little bit to broad, because the system can happily function without them.

    --
    I am TheRaven on Soylent News
  85. Analysis like that is not free by EmagGeek · · Score: 1

    Coverity is not a charitable organization, so the only question I have is: "who paid for the analysis?"

    I don't believe Google would have paid an outside firm. After all, people at Google view themselves as "the best of the best."

    I suspect Apple might have had something to do with this.

    1. Re:Analysis like that is not free by wonkavader · · Score: 1

      If Apple is paying to find bugs so they get fixed, well way to go Apple!

      Personally, I suspect it's more likely that Coverity wanted some press.

      But really, it'd be great to have Apple funding this stuff.

    2. Re:Analysis like that is not free by delinear · · Score: 1

      Agreed on the press point. If you were a firm who made their money by highlighting issues in other people's code, wouldn't you leap at the chance to highlight issues with the code of one of the biggest companies on the planet - the fact that it's open source means you can do this publicly and simply. It doesn't even matter if Google are already aware of most of these and are working to fix them - so much the better, you go from "the software that found Google's bugs" to "the software that helped fix Google's bugs".

    3. Re:Analysis like that is not free by Anonymous Coward · · Score: 0

      http://scan.coverity.com/

      I don't believe Google would have paid an outside firm. After all, people at Google view themselves as "the best of the best."
      That doesn't mean they have all the skill sets. They don't have a static analysis tool.

  86. Re:The most interesting thing about that article.. by serviscope_minor · · Score: 1

    It "dominates" in the same way Windows dominates PCs...a fractured mess controlled by the carriers,

    One can always buy sim-free phones. Yuo have to pay up front, but it's your phone.

    with their own unremovable junkware, their own app stores, and their own differing hardware features.

    Junkware is annoying, but I'd count differing hardware as a fearture rather than a bug. It gives you choice.

    Also, all "app stores" suck compared to a proper package manager.

    Here's an article you won't see written about the iPhone: How Can I Tell If An Android App Is Malware?

    You know there have been iPhone apps with hidden functionality, right? Those could just as easily have been malware.

    Personally, I'm not too excited about the idea of Google owning search, advertising, email, chat, documents, phones, netbooks, blogs, etc., all while skirting the edge of privacy.

    Yep.

    I'm not really interested in replacing one Micorosft with another.

    Yep.

    Apple is more concerned with being the best in a market, not #1 in a market.

    Apple are every bit as bad, given half the chance. And their phones are far too locked down. At lerast with Android, you don't have to use an app store if you do not want to.

    Anyway, I want an N900. That looks nice to me than either Android ir the iPhone.

    --
    SJW n. One who posts facts.
  87. Re:The most interesting thing about that article.. by digitalchinky · · Score: 1

    Technically you are correct : ) I have updated my definition of 'astroturf'

  88. Re:The most interesting thing about that article.. by drsmithy · · Score: 1

    A lot of people - myself included - refer to Darwin when talking about the OS, and Mac OS X when talking about all of the stuff that Apple bundles on the install CD (including Quartz, Cocoa, and so on).

    They're you're being inconsistent, and making arbitrary distinctions to support your bias.

    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.

    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. They all seem to suffer from Goldilocks syndrome, since not being able to pop up a bash shell isn't "graphical" _enough_, while drawing windows and using a mouse for input is _too_ "graphical".

  89. Re:The most interesting thing about that article.. by msauve · · Score: 1

    "When most technical people say OS, they mean the program that controls access to the hardware and provides system services- the kernel."

    So, for example, Linux is an OS when running on bare hardware, but if you're using it in a virtual machine on a Windows host, you're really running Windows as an OS? OK, if you says so.

    --
    "National Security is the chief cause of national insecurity." - Celine's First Law
  90. Re:The most interesting thing about that article.. by TheRaven64 · · Score: 2, Informative

    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 X.org instead on an OS X system, although the X11.app from Apple runs on top of Quartz. There are other Darwin distributions which only include X.org 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.

    --
    I am TheRaven on Soylent News
  91. And He shall be named by ThatsNotPudding · · Score: 1

    Pollyanna.

  92. Re:Serious first post by gfolkert · · Score: 1

    Did you read TFA?

    They said that the level of bugs per 1000 lines is very much less than half the "normal" amount. Though yes more than the Linux kernel itself, but some of the bugs were already addressed before release. I'd like to see *YOU* do better with getting the OS on a Mobil Device.

    I mean, come on, exactly how is a remote exploit (quite a few of the bugs are this type) going to happen on these phones when these things don't even listen on what is typically expected on the "network" and then even if it does, its typically been "rooted" (and they should get all they have coming to them if they don't know why they rooted and expect it to behave just like a non-rooted one) and even then... at least on Verizon doesn't allow any connection listening services on its "mobile" ip address ranges in any case.


    How about Apple let Coverity do the same run down on iOS? Never happen, at least with public results.
    Better yet, Windows Phone 7? Hah... never happen period.
    Nokia's stuff? better chance of winning the Mega Lottery.

    --
    greg, REMEMBER ED CURRY!!!
  93. Re:Serious first post by imakemusic · · Score: 2, Informative

    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:
    Blogger
    Youtube
    Picasa
    Sketchup

    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.

    --
    Brain surgery - it's not rocket science!
  94. Re:The most interesting thing about that article.. by Kireas · · Score: 1

    I'd refer to myself and a hell of a lot of people I know as 'technical people', and we still refer to the OS as the top level framework. We call the kernel the, wait for it...kernel. It keeps things simple if you don't decide to branch out your own language from what the normal people use.
    It's like ping and latency. Yes they are different, but only a right asshat would start complaining if someone says in a video game "Damn I have a high ping". Met one of those guys so far.

    --
    To much anime is bad for the brain...desu.

    Sorry. Couldn't help it.
  95. Re:The most interesting thing about that article.. by Kireas · · Score: 1
    I'm in Europe. I see about 8 Android phones to every one iPhone (of any generation). About 1 in each 8 of those phones is the carrier locked Nexus One. So this 'big hit' of your's may not happen.

    But yeah, OS X is Unix based, not Linux, as I recall.

    --
    To much anime is bad for the brain...desu.

    Sorry. Couldn't help it.
  96. Re:The most interesting thing about that article.. by Kireas · · Score: 1
    This could be because people are being freed from the reality suspension devices as the iPhone's market saturation decreases...D:

    Quick! Call Steve! He needs to increase the power levels!

    --
    To much anime is bad for the brain...desu.

    Sorry. Couldn't help it.
  97. Re:The most interesting thing about that article.. by Kireas · · Score: 1

    Here's an article you won't see written about the iPhone: How Can I Tell If An Android App Is Malware?

    Sure you will! Researcher warns of risks from rogue iPhone apps

    --
    To much anime is bad for the brain...desu.

    Sorry. Couldn't help it.
  98. i wonder.. by ltcdata · · Score: 1

    i wonder how many bugs are in closed source handset operating systems...

  99. Re:The most interesting thing about that article.. by Anonymous Coward · · Score: 0

    Who doesn't?

  100. Anonymous Coward by Anonymous Coward · · Score: 0

    Not very surprising.

    That's why you shouldn't let your Developers "Test" their applications. That's why you should hire a team of QA Testers.

  101. A better look at it by Mordocai · · Score: 2, Interesting

    http://www.esecurityplanet.com/features/article.php/3910891/Android-Code-at-Risk.htm seems like a better article to me, as it actually gives you information. For instance, to answer one commenter I saw, it mentions that the code from the vanilla linux kernel has fewer flaws than the code that is Android specific. It also mentions this gem: "We found that the Android kernel had about half the defect density that you would expect, compared to other industry average codebases of the same size," Andy Chou, Chief Scientist and co-founder of Coverity told InternetNews.com."What that means is that a defect density of one defect per approximately one thousand lines of code is industry average, according to our measurements – for the Android kernel, the defect density was about 0.47." According to the same source, the defect density if you look at Android only code is .7 per a thousand lines, so still below the industry average. In short, Android is more secure than most other kernels that Coverity has analyzed.

  102. Re:The most interesting thing about that article.. by Anonymous Coward · · Score: 0

    When most technical people say OS, they mean the program that controls access to the hardware and provides system services- the kernel.

    These people you call "technical"... They aren't, not if they get confused about such basic terms as "operating system" and "kernel".

  103. Re:The most interesting thing about that article.. by delinear · · Score: 1

    It's certainly not as clear cut as you are suggesting. Apple have a good percentage of the market right now, but the majority of growth is in Android (that's largely people moving from non-smart phones to smart phones, so it will be interesting to see how this plays out once that trend levels off), okay that's to be expected since they're starting from simpler roots, but I'd hardly say Android over here are feeling any kind of "hit", and we've had iPhones on other carriers for a good while.

  104. Bug discovery on an iPhone? by bcrosbie · · Score: 1

    Serious question. Would the discovery of bugs like these be possible on the iPhone due to it's closed nature?

    1. Re:Bug discovery on an iPhone? by Anonymous Coward · · Score: 0

      If apple uses such a tool then yes.

  105. The interesting question is... by Anonymous Coward · · Score: 0

    ...how many of those allow me to root and own again my 2.2 HTC Desire.

    I made the mistake to update to 2.2 and then I got into an area where there is no clear way to root it :(

  106. Re:Serious first post by Jeremiah+Cornelius · · Score: 1

    All done before.

    --
    "Flyin' in just a sweet place,
    Never been known to fail..."
  107. Re:Is it just me? by Anonymous Coward · · Score: 0

    The bugs were found by static analysis.

  108. Re:Serious first post by Anonymous Coward · · Score: 0

    All done before.

    But how many of them were released at the same price of Free?

  109. Re:Serious first post by poetmatt · · Score: 1

    so wait, you think that when people add functionality it's not going to reduce security?

    do you even know what programming and programatically introducing security means?

    It means your choice is : functionality or security. You don't get both.

    At least they're using fairly current kernels, if they weren't then I'd say it's different.

  110. Different builds by inf0rmer · · Score: 0

    With so many different builds of Android, these issues may or may not exist on other phones..

  111. Re:Serious first post by Anonymous Coward · · Score: 0

    Don't forget:

    Voice Search (For Android)
    Android OS
    Nexus One Smartphone
    Chrome OS (coming out soon)
    Google Night Sky
    Buzz

  112. Re:Serious first post by imakemusic · · Score: 1

    Ok, so who has made something completely new?

    Oh, also Chrome OS (as far as I know, the first net-based OS) and Android (as far as I know, the first Linux phone OS).

    --
    Brain surgery - it's not rocket science!
  113. Re:Serious first post by Jeremiah+Cornelius · · Score: 1

    ChromeOS is Linux, with the userland stripped bare and a browser for a shell.

    --
    "Flyin' in just a sweet place,
    Never been known to fail..."
  114. Re:The most interesting thing about that article.. by mweather · · Score: 1

    XNU IS the match kernel. Darwin is the OS, which includes XNU match kernel.

  115. Re:The most interesting thing about that article.. by mweather · · Score: 1

    mach, not match. You get the idea.