Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
Get HideMyAss! VPN, PC Mag's Top 10 VPNs of 2016 for 55% off for a Limited Time ×
Bug Security Linux IT

Serious Linux Kernel Vulnerability Patched (threatpost.com) 85

msm1267 writes: A patch for a critical Linux kernel flaw, present in the code since 2012, is expected to be pushed out today. The vulnerability affects versions 3.8 and higher, said researchers at startup Perception Point who discovered the vulnerability. The flaw also extends to two-thirds of Android devices, the company added. An attacker would require local access to exploit the vulnerability on a Linux server. A malicious mobile app would get the job done on an Android device. The vulnerability is a reference leak that lives in the keyring facility built into the various flavors of Linux. The keyring encrypts and stores login information, encryption keys and certificates, and makes them available to applications. Here's Perception Point's explanation of the problem.
This discussion has been archived. No new comments can be posted.

Serious Linux Kernel Vulnerability Patched

Comments Filter:
  • by Anonymous Coward

    The summary downplays the threat to Linux servers with how the "local access required" is phrased. The PoC provided successfully escalates privileges from a local user to root. This is a very serious issue with serious remote exploitation risk.

    • by gweihir ( 88907 )

      A local exploit has no "remote exploitation risk" by its very definition. Your statement just shows that you have no clue what you are talking about.

      • A local exploit has no "remote exploitation risk" by its very definition. Your statement just shows that you have no clue what you are talking about.

        Except if combined with a remote vulnerability, perhaps in the web app running locally on the server, or your web browser running on your laptop.

        • by gweihir ( 88907 )

          If you have a remote vulnerability, then you already have a remote vulnerability. Get at least the basic terminology right!

  • by Anonymous Coward
    Why does the kernel need to store login info, certificates, and the like? Just wondering as it seems like that stuff belongs strictly in user context. (As you can see, I don't know much about Linux).
    • by Anonymous Coward

      For example for mounting network file systems. Could in theory be done in userspace, but on linux and windows is not.

      • Yep, this is the case if you're for example using AFS or NFS with Kerberos authentication, which is fairly common in enterprise environments.
    • Re:Question (Score:4, Informative)

      by castionsosa ( 4391635 ) on Tuesday January 19, 2016 @10:37AM (#51328759)

      One of the biggest things, is ensuring the data isn't swapped to disk in an unencrypted format.

    • Re:Question (Score:5, Informative)

      by ArsenneLupin ( 766289 ) on Tuesday January 19, 2016 @10:51AM (#51328889)

      Why does the kernel need to store login info, certificates, and the like?

      While the question is legit, it has nothing to do with the bug.

      The bug is a reference counting issue, where an attacker can trick the kernel to release a buffer and reallocate it to another purpose, while the original process still holds a reference to it. That process can then abuse its reference (from the old purpose) to mess with the buffer (in its new purpose) in such a way that it obtains root privileges.

      It just happens that the original purpose was indeed about key management. But the bug would work just the same way if that purpose was something else. And the vulnerability even exists if this kernel feature is not used at all. It is not about disclosure of keys or anything like this.

  • by cerberusss ( 660701 ) on Tuesday January 19, 2016 @10:16AM (#51328623) Homepage Journal

    Well, let's see how Google fixes this... Although Lollipop (5.0) has been out since june 2014, I can still order for example the HTC Desire 310 which comes with Jellybean (4.2).

    How are all of these Android versions in the wild going to get fixed?

    • by serviscope_minor ( 664417 ) on Tuesday January 19, 2016 @10:17AM (#51328633) Journal

      How are all of these Android versions in the wild going to get fixed?

      Haha they're not!

      Welcome to the new way of doing things. Updates are for old fuddy duddies.

      • Unless you're driving a somewhat recent Nexus...then you'll get an update fairly quickly.
        • Unless you're driving a somewhat recent Nexus...then you'll get an update fairly quickly.

          And if you're not, then the recent OS update broke the whole system and they don't intend to ever fix it.

        • by serviscope_minor ( 664417 ) on Tuesday January 19, 2016 @11:37AM (#51329367) Journal

          Unless you're driving a somewhat recent Nexus...then you'll get an update fairly quickly.

          I have a Nexus 4. It's still very much functional, but it's been EOL since May 2015, a scant 2.5 years after it was first released. By contrast my 8 year old eee 900 is happily running the latest version of everything.

          I'm typing this from my W510 laptop (at work---yay for slacking) which is now amazingly approaching 6 years old. It works great. It's running a 2 year old version of ubuntu (14.04 LTS) which will continue to be supported for another 3 years. However, I'll almost certainly upgrade to 16.04 and the laptop will keep on trucking (the 16G of RAM has stopped it aging badly) for many years to come.

          The state of mobile phones is beyond pathetic, compared to what we had for PCs.

          • I have a Nexus 4.

            Your Nexus 4 got Lollipop, which has SELinux turned on, which should block any access to this vulnerability.

            • by batkiwi ( 137781 )

              From the article:

              "The vulnerability affects any Linux Kernel version 3.8 and higher. SMEP & SMAP will make it difficult to exploit as well as SELinux on android devices. Maybe we’ll talk about tricks to bypass those mitigation in upcoming blogs, anyway the most important thing for now is to patch it as soon as you can."

              SELinux makes it difficult, but they're going to tell you how to get around it once it's fixed.

              SELinux doesn't block access to this vulnerability, it merely makes exploitation mor

              • SELinux doesn't block access to this vulnerability, it merely makes exploitation more complex.

                In Lollipop SELinux it does make it impossible. Nothing in the system used these syscalls, so access to them is completely disabled by SELinux. If you can obtain root you can disable SELinux, but if you can obtain root you don't need the vulnerability.

                In Marshmallow there might be some possibility. A couple of system services started using the feature, so the SELinux configuration was partially opened up. We'll see if it turns out that there is some way to exploit it in Marshmallow. I suspect not, but if

          • by antdude ( 79039 )

            Get back to work, slacker. ;P

      • It is a user's great hope, and the carriers' and oems' great dread, that SuperSU [google.com] is about to find itself installed on a vast new segment of the Android market. Here's hoping!

    • They won't, and that's deliberate by the phone manufacturers and carriers. They want you to keep buying new phones every 1-2 years.

    • Google will fix this by updating the ASOP with their fix in the latest version. Possibly even a few previous versions too.

      The problem is the handset makers and carriers won't push the updates down to the handsets they support.

      • by Anonymous Coward

        No, the problem is that Google doesn't flex its muscles and force manufacturers and carrirers to push the fixes to the end user.

        All Google has to do is to include a little clause in the terms of their agreements with manufacturers that says: must provide base system patches for at least 2 years, or else, no Google play services.

        That means no play store and no Google maps. That kills the device for 99â... of the people.

        They've disallowed the inclusion of play services to a manufacturer before for far mo

      • by Teun ( 17872 )
        Over here in The Netherlands there is an upcoming court case of the largest Dutch consumer organisation against the largest phone seller Samsung.
        They want the court to force Samsung to offer updates for at least 2 years after the last phone of a model has been available, presently it's at best 2 years since it appeared on the market.
        There is a good chance of winning as EU law stipulates a minimum warranty of 2 years.

        Once it has been decided in one EU country and for the largest manufacturer it should en
    • I wouldn't be surprised to see this not get fixed on most Android devices. I'd say, other than Nexus devices, the best way to ensure one gets patches is to move to CyanogenMod.

    • This vulnerability affects Linux kernel 3.18 and above. Android 4.1 comes with Linux kernel 3.0.31. My HTC One M8 running Marshmellow (Cyanogenmod 13) is still on kernel 3.4.0

    • by poltsy ( 1897872 )

      HTC Desire 310 kernel version appears to be 3.4.5. There's nothing to fix.

      • Most Android kernels have quite a lot of backported features from newer kernels so I wouldn't be sure just by looking at the version number. I've seen another Android system running on 3.4 which was vulnerable for that reason, not sure how many others are affected.
    • by Shawn Willden ( 2914343 ) on Tuesday January 19, 2016 @02:01PM (#51330595)

      Well, let's see how Google fixes this... Although Lollipop (5.0) has been out since june 2014, I can still order for example the HTC Desire 310 which comes with Jellybean (4.2).

      How are all of these Android versions in the wild going to get fixed?

      Since the bug didn't appear until kernel version 3.8, Jellybean devices are safe because Jellybean has kernel 3.4.39.

      Also, since Lollipop and Marshmallow have SELinux in enforcing mode, blocking access to the relevant syscalls, the bug is present but not exploitable on Lollipop and Marshmallow devices.

      This means that only KitKat devices (kernel 3.10) both have the bug and don't have SELinux blocking access to it. KitKat currently has about 36% market share.

      Incidentally, this also means that no Nexus devices are vulnerable. All devices newer than Galaxy Nexus have been upgraded to at least Lollipop, and so have SELinux protection. The GNex stopped at Jelly Bean, so doesn't have a vulnerable kernel (though there are other JB vulns).

    • After the stagefright bug, Google implemented a "rapid response" update system (i.e.) older systems could get security fix updates [but not necessarily feature enhancements]. This preserves the market for new devices but allows older ones to remain secure.

      Google rolled this out to its various vendors (e.g. Samsung, Moto, etc.). Several of them have pledged to honor this. Thus, I recently got an OTA [security] update from Samsung for my Galaxy S3 [that was EOL] to fix stagefright.

      There was a bit of NRE to p

    • by dohzer ( 867770 )

      They should fix it by making newer versions run intolerably slow on old devices, forcing people to buy a new phone.

  • by Anonymous Coward
    I don't know if Linux should be held to a higher standard than Windows, but critical vulnerablilities like this seem to be becoming more and more common (or are just being found more since people are actually starting to look for them). Think how many IoT systems are susceptible to this and will never be updated. This is serious business.
    • by Viol8 ( 599362 )

      "but critical vulnerablilities like this seem to be becoming more and more common"

      Probably a combination of the kernel becoming ever more complex (or more code anyway), and ever more scrutiny.

    • from my perspective i think we need tools that find these serious bugs in millions of lines of code and point them out.. I am thinking AI would work great at this. it can look for similar bugs to what it have been trained to do.. This stuff is getting too complicated for mere mortals to fix and look for. Not even LInus can find every bug.
      • Because nobody's thought of code analysis before.

        I'm skeptical trying to design an AI to do it would be any easier or more effective than what we're already doing.

      • by DarkOx ( 621550 )

        We have those tools, they are called static source code analyzers, they are even very effective at identifying certain classes of bugs, though they won't find everything and the more clever the code is they worse they do as rule. Kernels unfortunately even when not being authorized by *real programers* tend to have some clever code by necessity and for performance reasons.

               

      • LOL. AI. AI doesn't exist, and likely never will exist. You don't need AI to find bugs like this. You just need software tools, which already exist. Unfortunately it doesn't mean they are applied well or cover all cases.
    • IoT systems may be running older, smaller kernel versions, but yeah another reason to only buy fully open gear you can patch yourself, if you don't build your IoT gear from scratch. Even then it is a PITA to have to run around and check every device you have each time a serious security flaw is found, but that's life in Nerdsville for you.
  • by Anonymous Coward on Tuesday January 19, 2016 @10:19AM (#51328637)

    I don't run Serious Linux, so I'm fine.

  • Out of curiosity, I decided to see how long it would take to overflow. Looping 2^24 times took 7.5 seconds on my laptop, indicating overflowing the 32bit ref would take about 1/2 hour. (That works out at 2.3m syscall's per second.)

    • by Anonymous Coward

      So on a phone, it would take about six hours, drain the entire battery, and probably cause the thing to explode...

  • It affects 3.18 and later according to http://perception-point.io/201... [perception-point.io] rather than 3.8.
    • by gweihir ( 88907 )

      Read again. Their exploit code is against 3.18, but they say that 3.8 and later is affected.

  • by Anonymous Coward

    Since ESXi is based on the Linux kernel, is it also affected? VMWare is TERRIBLE about patches and security updates, so I have to wonder how many months will pass before this is fixed, if it is an issue.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      ESXi is NOT based on the Linux kernel.
      It implements some driver api layers through the vmklinux module to allow Linux kernel modules to be ported to ESXi... similar to how ndiswrapper in Linux works to allow you to run windows drivers on Linux. Also ESXi 5.5 moves away from this with "native drivers" like elxnet.

      The other similarity is some open source software is recompiled and included such as busybox.

      IMHO it is closer to BSD then Linux... but it's actually it's own beast.

    • by ebvwfbw ( 864834 )

      Since ESXi is based on the Linux kernel, is it also affected? VMWare is TERRIBLE about patches and security updates, so I have to wonder how many months will pass before this is fixed, if it is an issue.

      AC - you should know what you're talking about. Obviously you have no clue. I've been using it for years and they update all the time. It's easy to patch. I also have the free home version. Same story. Easy to patch. Just because you never bothered to look doesn't mean it's true.

  • The more I learn about the smartphone compute environment, the less I want one.

    .
    There appears to be no way to reign in the apps.

    • One way to reign in apps is to not install any app that you aren't familiar with. Malicious apps can cause the issue. Fully vetted apps should be fine. Never side-load.
  • According to a comment on Phoronix ( http://www.phoronix.com/forums... [phoronix.com] ), the cause is a goto:

    "And the funny thing is? The guilty line is a fucking GOTO. Everyone using this atrocious coding practice should be shot in the head." ("magika")

    User "stevenc" adds: "It's a pretty common pattern of trying to emulate Objected Oriented Programming in C. Try to construct one or more 'objects', otherwise fall back to one or more 'destructors' at end of the function. They'd even implemented their own reference counters

    • by fche ( 36607 )

      "And the funny thing is? The guilty line is a fucking GOTO."

      No; the goto wouldn't have mattered - the missing key_put() could have been put at either location, with or without the goto.

      • I hope you do understand that the fact that you _could_ do it right is not an excuse? The goto makes it easy to get an indigestible spagetti mass of code that defies code analysis and leads to this sort of bug being introduced... The problem with the goto is not that it introduces a four-letter word, but that it makes it easy to make precisely this type of mistake.

        • by fche ( 36607 )

          The same bug would have existed without the goto business:

          if (keyring == new->session_keyring) {
                key_put(...)
                mutex_unlcok(...)
                abort_creds(...)
                return 0;
          }

          would have been just as buggy without the key_put(). The goto was neither necessary nor sufficient for this bug.

        • by Anonymous Coward

          You dipshit. The use of goto had nothing to do with this. The use of goto's in the kernel, and in other systems programming contexts, has nothing to do with emulating Object Oriented programming. Its good old fashioned exception handling. You either use nested if-thens or goto's. If can fuckup the cleanup code in either case.

          Goto spaghetti comes from going up and down in the control flow. The use of goto's to unwind during an exception is good old fashioned linear programming. If this confuses you, s

          • Do you really go through life starting conversations with "you dipshit"? How many times have you been hit in the face for that yet?

            Oh wait, is that you Linus?

    • by andyn ( 689342 ) on Tuesday January 19, 2016 @07:24PM (#51333091)

      Guess what! it has nothing to do with OOP emulation. All cleanup in a C program has to be done explicitly by the developer, be it coded in object-oriented, functional, imperative or whatever the paradigm-of-the-week is.

      Furthermore, the way kernel devs use goto for cleanup is one of the ways that actually keeps the code simpler and less prone to errors. There are a few alternatives to do cleanup in complex code:

      1. Don't do error checks. In your average C101 homework it's often assumed that many syscalls cannot fail. Obviously, the absolute minimum required in a real world program is a simple assert that stops the program before it can misbehave. Any real-world program that cannot lose data or crash the whole system such as office programs, databases and kernels obviously cannot do this.
      2. Do an early return and clean up all data so far. Very error prone as the cleanup code has to be replicated in multiple places.
      3. if/do-while(0)-break wrapping of code. Easy as long as there is one tier of resources to allocate. Any more and the function becomes arrow code. [stackoverflow.com]
      4. Wrap the constructors and destructors in a macro to emulate RAII. The result is still arrowish, although the cleanup is harder to fail. Not allowed in many projects due to an undeserved loathing of macros.
      5. Split the code into multiple functions. Now you have to pass around the state in function parameters. Having the code split into multiple functions makes the it more prone to logic errors.
      6. Use goto to jump to the cleanup section. All relevant code is kept in the same function and the code between alllocations and frees stays flat and concise.

These screamingly hilarious gogs ensure owners of X Ray Gogs to be the life of any party. -- X-Ray Gogs Instructions

Working...