Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Google Android Security

Google Fixes Zero-Day Kernel Flaw, Says Effect on Android Not Really That Bad (csoonline.com) 132

itwbennett writes: Google has developed a patch for Android in response to a flaw in the Linux kernel and has shared it with device manufacturers. That doesn't mean the patch will hit users' phones right away, though. It might take weeks. But that's ok, says Google, because most Android devices are unlikely to run vulnerable kernel versions, and those that do are protected by SELinux.
This discussion has been archived. No new comments can be posted.

Google Fixes Zero-Day Kernel Flaw, Says Effect on Android Not Really That Bad

Comments Filter:
  • Ridiculous (Score:2, Insightful)

    by Anonymous Coward

    If there's a security fix for iOS, I can download and install it right away. There's no reason that shouldn't be the case for Android. This is ridiculous. And what if the manufacturers have disabled SELinux or set it to be permissive? It's a matter of time before a worm like Blaster hits Android and does some serious damage. Fix your damn security model!

    • Re:Ridiculous (Score:4, Insightful)

      by phantomfive ( 622387 ) on Thursday January 21, 2016 @10:15PM (#51348351) Journal

      If there's a security fix for iOS, I can download and install it right away. .... Fix your damn security model!

      Some people would say that security doesn't depend on fast updates: security depends on not having security vulnerabilities in your software to begin with.

      • Re: (Score:3, Insightful)

        by SirSlud ( 67381 )

        You're right. Some people would say that security depends on being perfect. Those people however are living in a dream world where trying to prevent mistakes and fixing mistakes are somehow physically mutually exclusive.

        • You're right.

          I have to say we are in total agreement.

          Some people would say that security depends on being perfect.

          Whether perfection is possible or not: that is a philosophical question.
          More practically, we can easily do better in security than we are doing now by an order of magnitude.

          • by Merk42 ( 1906718 )
            Please write something more complicated than "Hello World" that has no vulnerabilities. Also it must be invulnerable to unknown future attack vectors.
            • This topic has been brought up before. DJB showed with qmail that a substantial program can be written with no serious vulnerabilities.
              OpenBSD shows we can do better on security by an order of magnitude (and if you listen to the techniques they use, it's not super-hard).

              There's no excuse for the garbage, vulnerable software we are subjected to.
              • by Merk42 ( 1906718 )
                Both OpenBSD and qmail have had vulnerabilities, so I guess they're garbage too.
                • Android had more vulnerabilities in the last month than OpenBSD has had in the last decade. If you can't see a difference here, you need to have your brain adjusted. There is some sloppy programming going on in Android that doesn't need to be.
                  • by Merk42 ( 1906718 )
                    Security through obscurity!
                    Seriously though, I'm not the one that said "security depends on not having security vulnerabilities in your software to begin with."
                    • Seriously though, I'm not the one that said "security depends on not having security vulnerabilities in your software to begin with."

                      Yeah, it's true. A fully patched Android system is still vulnerable. Any attacker who wants to put in the effort can find a vulnerability.

      • by cfalcon ( 779563 )

        Well, given that we're discussing a case where Android has a vulnerability, then the speed of the update is pretty relevant.

      • Yeah, because in the history of software development, there are exactly zero products that have shipped, and are 100% free of bugs and flaws. So don't worry about how fast you can patch it.

      • by kmoser ( 1469707 )

        Some people would say that security doesn't depend on fast updates: security depends on not having security vulnerabilities in your software to begin with.

        Security doesn't depend on not having security vulnerabilities in your software to begin with; security depends on preventing people from discovering and exploiting your existing security vulnerabilities.

        • security depends on preventing people from discovering and exploiting your existing security vulnerabilities.

          That's a bandaid that definitely works sometimes.

    • Out of interest can you point to any in the wild infections for Android?

      • Should they wait for one and then act?
    • Re: (Score:2, Insightful)

      by Anonymous Coward

      Nobody can deny the the Android update situation is a complete mess. But Apple aren't exactly security darlings here. Sure, you get the updates immediately... when Apple gets around to it. You still have to live with years-old known vulnerabilities, and major issues being held back for more product-cycle friendly release timescales.

    • by raymorris ( 2726007 ) on Thursday January 21, 2016 @10:39PM (#51348429) Journal

      > what if the manufacturers have disabled SELinux

      Yes, if an OEM disabled the security model, that would be a security problem. Tautology much? That hasn't happened on any relevant device.

      Oh I know, if the manufacturer installed a botnet malware and gave access to spammers, that would be a problem too! Oh my, a manufacturer could mess up the device the manufacturer!

      • That hasn't happened on any relevant device.

        I really doubt it ever would because of the whole SEAndroid architecture built on top of it. An OEM would seriously have to go out of their way to not have it working.

      • Right? And here's the thing: Apple fans (I'm a user, but not a fan, it's a tool and it does a job, it's not deserving of fandom) will insist that issues that affect rooted or non-Nexus Android devices are worse than issues that affect jailbroken iOS devices, but they're really one-in-the-same. The reality is that rooting an Android device is a departure from the vanilla Android binaries and configuration provided by Google, as is a manufacturer replacing Android binaries and configurations with their own or
    • Re:Ridiculous (Score:5, Informative)

      by Shawn Willden ( 2914343 ) on Friday January 22, 2016 @12:06AM (#51348617)

      what if the manufacturers have disabled SELinux or set it to be permissive?

      Then those manufacturers' devices cannot pass the Android Compliance Test Suite, and they have no right to call their devices Android and cannot use Google's apps. SELinux, in enforcing mode and with the Google-defined configuration (mostly; OEMs can make tweaks in some areas, but not the ones relevant to this vulnerability) has been a formal Android compliance requirement since Lollipop.

      It's a matter of time before a worm like Blaster hits Android and does some serious damage.

      I doubt it. Android is vastly more secure than Windows was (or even is... and Windows is much better than it was when Blaster hit). The lack of updates delivered by OEMs has caused the Android security team to focus on defense in depth, and the system is working pretty well (see last year's report [googleusercontent.com] -- or wait a bit for the new report which should be out in a few weeks). In particular, less than 0.1% of Android devices that use the Play store have any potentially harmful apps (PHA) installed, and that PHA definition is much broader than just traditional malware. Of the PHA apps, only about 5% try to exploit vulnerabilities; the rest focus on social-engineering the users.

      So, 0.005% of Android devices have some exploit-using malware on them. And AFAIK there are no Android worms. So, I really, really doubt Android is ripe for a Blaster.

      Fix your damn security model!

      The Android security model is actually very good... with one glaring exception, which is the update problem. But Google has committed to a monthly patch cycle for Nexus devices, and several other OEMs have hopped on that patch train. Thanks to that, carriers are being forced to get updated software through QA faster, and the focus on monthly updates is pushing OEMs to simplify their offerings to make updating them more practical (you probably won't see a visible reduction in number of offerings; but in the future I expect each model will have a handful of SKUs, at most, rather than hundreds as is often the case today).

      The update problem isn't going to get fixed overnight, but I think it is getting fixed, at least from top manufacturers. The next step is for consumers to insist on well-defined and sufficiently-lengthy support and update policies as a condition of purchase, to force all of the rest to get with the program.

      In the short term, if you want the most secure and up-to-date Android device, buy Nexus, but I expect soon others will be challenging Google for that spot.

      (Full disclosure: I'm a Google engineer, on the Android security team.)

      • Google could require that manufactures subscribe to some sort of security update model as a requirement before using android software. By not doing this, Google is opening itself up to tremendous liability should something bad ever happen. You may not think so, but some jury someday may think differently. I know of what I speak, though I would prefer not to give full disclosure.

      • No they won't, because too many of them insist having everything their way once you guys sign off on their use of Android. This leads to everything from locked bootloaders, out of date kernels, no OS patches at all, etc. This isn't getting better, it has been steadily getting worse, with the number of devices updated by OEMs and carriers to Lollipop and Marshmallow being lower than any previous versions of Android. Many places are still selling flagship models with Lollipop that don't even have Marshmallow

        • with the number of devices updated by OEMs and carriers to Lollipop and Marshmallow being lower than any previous versions of Android

          specifically because, starting with Lollipop, carrier apps are installed on first boot (based on the inserted SIM, so no carrier apps if no SIM is installed) and can be removed by the user once installed. They're no longer part of the firmware, thus no longer require carrier customization. which removes the carrier's ability to require their approval before updates are pushed by the OEMs. While this makes it easier for OEMs to push updates, they can only do so where standalone versions of the carrier apps a

      • In the short term, if you want the most secure and up-to-date Android device, buy Nexus, but I expect soon others will be challenging Google for that spot.

        Except when Google discontinues your device support. :(

        Please encourage your superiors to release official Marshmallow images and updates for the Google Nexus 4.

        • In the short term, if you want the most secure and up-to-date Android device, buy Nexus, but I expect soon others will be challenging Google for that spot.

          Except when Google discontinues your device support. :(

          Please encourage your superiors to release official Marshmallow images and updates for the Google Nexus 4.

          Two years of updates and three years of security patches is better than anyone else is offering. Apple sometimes does a bit better than that, but they don't make any promises.

        • They support their phones for at least as long as Apple. In fact, they've made a legally binding commitment [google.com] to supporting devices for at least a certain period of time: major version updates for at least 2 years from date of first sale; security updates for at least 3 years from date of first sale or 18 months from date of removal from the Google Play Store, whichever is longer.

          Meanwhile, Apple and Microsoft have done no such thing. I'm not sure of Microsoft's track record regarding device support, but I
      • How are consumers going to demand that when all the OEMs are varying levels of useless. Google has the power to pressure them to be better but doesn't seem to want to use it.

        • How are consumers going to demand that when all the OEMs are varying levels of useless. Google has the power to pressure them to be better but doesn't seem to want to use it.

          Google has a lot less power than you think. We have to tread carefully to keep the ecosystem unified and moving forward together. If Google is too heavy-handed, some of the bigger OEMs are totally capable of taking AOSP and going their own way.

          • Samsung, HTC and various carriers have already done that to a degree and that's part of why updates aren't provided in a timely manner. The Android ecosystem is a mess leaving consumers vulnerable and Google is the only org that can pull it together again. I don't envy you having to do that but the current status quo is not good enough.

      • Thanks to that, carriers are being forced to get updated software through QA faster

        Why is that even a thing? I can understand changes to the modem being an issue but isn't Android modular enough that things like a kernel patch, or some updated software can be delivered without a carrier having to vet anything?

        • Why is that even a thing? I can understand changes to the modem being an issue but isn't Android modular enough that things like a kernel patch, or some updated software can be delivered without a carrier having to vet anything?

          You would think so. Unfortunately, the way it is unless you have a Nexus phone is that first the manufacturer has to vet the patch, then the carrier has to vet it. In part because both pile useless software onto the handset that might rely on whatever is being patched. Even more unfortunately, neither of them have any vested interest in actually applying the patch because they would rather sell a new handset and get you into another contract instead.

          While I am not an Apple fan, I think their model of removi

          • Unfortunately, the way it is unless you have a Nexus phone is that first the manufacturer has to vet the patch, then the carrier has to vet it.

            Same on Nexus, actually, though Google has managed to streamline the process a bit. The manufacturer vetting step is mostly cut out. Mostly.

            While I am not an Apple fan, I think their model of removing other actors from the security equation is beneficial.

            It's worth noting that Apple also has to go through the carrier vetting step.

            The biggest difference between Apple/Nexus and other OEMs, IMO, is variety. Samsung, for example, has thousands of different system images to update, and each one has to be validated by the carriers. Nexus and Apple keep it down to a handful. The OEMs have done this to themselves, obviously,

        • Thanks to that, carriers are being forced to get updated software through QA faster

          Why is that even a thing? I can understand changes to the modem being an issue but isn't Android modular enough that things like a kernel patch, or some updated software can be delivered without a carrier having to vet anything?

          Hell if I know. It makes no sense to me, either.

        • by tlhIngan ( 30335 )

          Thanks to that, carriers are being forced to get updated software through QA faster

          Why is that even a thing? I can understand changes to the modem being an issue but isn't Android modular enough that things like a kernel patch, or some updated software can be delivered without a carrier having to vet anything?

          No, because some carriers get anal and demand things work in certain ways.

          It's a lot better now, but in the past, things like the color of the send button must be a certain shade of green, for example.

          • It's a lot better now, but in the past, things like the color of the send button must be a certain shade of green, for example.

            That's not relevant. A lot of those features especially the candy is controlled by individual apps. There's no reason a whole kernel upgrade should have any visible impact on the user or any of the applications at all. My point was why isn't the system modular enough that these customisations aren't a problem. It's not like I have to rebuilt my linux server every time a new package or security fix is released.

        • Because carriers make their own, modified distribution of Android. Which of course, git is set up to handle, but sometimes the carriers make a mess of things.

          It's not entirely the carrier's fault, because sometimes Google makes some pretty big changes in the core OS. So, for example, imagine if the carrier had to change the screenshot utility to work with their hardware (surprisingly common). Then in a later version of Android, google changed the internal screenshot system. In order to update to the lates
          • I'm talking about minor updates and fixes here not API changing modifications. One should be able to apply a kernel patch without wondering if the entire system is going to melt into a puddle as a result.

            • One should be able to apply a kernel patch without wondering if the entire system is going to melt into a puddle as a result.

              That's true, especially since the kernel team is really good about maintaining backwards compatibility.

      • The next step is for consumers to insist on well-defined and sufficiently-lengthy support and update policies as a condition of purchase

        That would be nice if a user had anything to say about the stuff he would buy. You can demand every reasonable thing in the world, but "then don't buy it" is the only answer you will ever get.

        Not buying a phone might give you a good feeling for living up to your principles, but it will not result in a phone with reasonable support.

      • The Android security model is actually very good....but Google has committed to a monthly patch cycle for Nexus devices,

        If you have to release security patches every month, then your security model is definitely NOT good. You have serious problems with your code.

        • The Android security model is actually very good....but Google has committed to a monthly patch cycle for Nexus devices,

          If you have to release security patches every month, then your security model is definitely NOT good. You have serious problems with your code.

          Utter nonsense.

          There is no way that any system as large and complex as a modern personal computing operating system is going to be completely bug-free. If you believe otherwise, you're either clueless or living in a fantasy world.

          • Utter nonsense.

            You're wrong. Even if you were correct in your assumption that large systems can't be secure, then you would still be wrong in saying that such security is good. Bad security is bad security, even if you think it's the best possible. Software with many vulnerabilities is not secure.

            If you believe otherwise, you're either clueless or living in a fantasy world.

            I like the fact based, well-reasoned argument you have there. It's so convincing.

            • You've clearly never tried to build large-scale secure software systems. There's no point in discussing this with you.
            • Oh, something for you to consider: http://www.openbsd.org/errata5... [openbsd.org]

              OpenBSD is much smaller and simpler than any mainstream OS, and has had a laser focus on security for years. Security is their number one goal, above usability, features or anything else... and yet they need more-than-monthly updates to fix security defects. That should give you an indication of just how hard a problem this is.

    • by jrumney ( 197329 )
      If there's a security fix for iOS you don't even hear about it until Apple is ready to ship on all devices they are still supporting.
      • by Merk42 ( 1906718 )

        If there's a security fix for iOS you don't even hear about it until Apple is ready to ship on all devices they are still supporting.

        no, but if there is a security vulnerability you do hear about it..

    • by jeremyp ( 130771 )

      There is a reason why it shouldn't be the case for Android. The reason is that Google doesn't make the phones. This patch will have to be tested on each manufacturer's devices before it is made available. Google isn't going to do that, the manufacturers are. Well, you'd hope the manufacturers are.

      This is the fundamental difference between the Android and iOS ecosystems, Android is fragmented, iOS is monolithic.

    • Or, as a user, educate yourself and buy a Nexus device which, much as the iPhone gets its updates directly from Apple, gets its updates directly from Google. I've noticed that Google is generally quicker to update my Nexus 6 than Apple is to update my iPad Air when a flaw is publicly disclosed; I would assume the same when the flaw is not publicly disclosed but there is not frame of reference for this.
  • In case anyone cares, the bug was improper deallocation. Sloppy programming.
  • by frovingslosh ( 582462 ) on Thursday January 21, 2016 @11:21PM (#51348527)

    That doesn't mean the patch will hit users' phones ever, though.

    There, I fixed it for you.

  • Weeks? (Score:5, Insightful)

    by cyber-vandal ( 148830 ) on Friday January 22, 2016 @01:59AM (#51348829) Homepage

    How about months or never. The upgrade situation on Android is a joke unless you buy from Google.

    • by nnull ( 1148259 )
      Samsung and Verizon devices will probably never get an upgrade. Took forever to get an update for my Note 12.
    • How about months or never. The upgrade situation on Android is a joke unless you buy from Google.

      Yes but so are most attack vectors. When a problem gets discovered in Windows, IE, Flash, Acrobat etc it's sometimes a matter of hours / days before exploits are in the wild, sometimes the exploits are out before the the problem is discovered.

      In the Android world I've yet to actually hear of a wide spread exploit self propagating between devices and turning them all into mass zombies. Typically we only hear about devices that were compromised via some dodgy app with questionable permissions, which is a far

      • The problem with Android is that even when the flaw is fixed by Google it doesn't make it onto the majority of the phones out there. That's not good enough. Microsoft would never escape criticism for ignoring flaws but for some reason Android OEMs seem to get a free pass.

        • It's good enough for the Nexus device in my pocket. I don't own the majority of Android devices out there and neither would an educated consumer. Those OEMs aren't getting a free pass, I voted with my dollars and made them irrelevant, so it's not worth my time to jump on them.
        • The free pass is given due to the attack vector. I would give Microsoft a free pass too when their bugs have very little impact or are incredibly unlikely to be exploited.

          Just like I gave Linux a free pass when the malware was discovered last week and we all couldn't help but joke at the fact that parts of it didn't work, and when they did work it didn't do so very widely.

    • How about months or never. The upgrade situation on Android is a joke unless you buy from Google.

      Not only is Motorola pretty good about updates, but I can get an AOSP build for pretty much any of their phones. I don't know if there are any other manufacturers as reputable, but I've been happy enough with Moto that my next phone will probably also come from them.

Repel them. Repel them. Induce them to relinquish the spheroid. - Indiana University fans' chant for their perennially bad football team

Working...