Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Security Red Hat Software Linux

'Most Serious' Linux Privilege-Escalation Bug Ever Is Under Active Exploit (arstechnica.com) 109

Reader operator_error shares an ArsTechnica report: A serious vulnerability that has been present for nine years in virtually all versions of the Linux operating system is under active exploit, according to researchers who are advising users to install a patch as soon as possible. While CVE-2016-5195, as the bug is cataloged, amounts to a mere privilege-escalation vulnerability rather than a more serious code-execution vulnerability, there are several reasons many researchers are taking it extremely seriously. For one thing, it's not hard to develop exploits that work reliably. For another, the flaw is located in a section of the Linux kernel that's a part of virtually every distribution of the open-source OS released for almost a decade. What's more, researchers have discovered attack code that indicates the vulnerability is being actively and maliciously exploited in the wild.

"It's probably the most serious Linux local privilege escalation ever," Dan Rosenberg, a senior researcher at Azimuth Security, told Ars. "The nature of the vulnerability lends itself to extremely reliable exploitation. This vulnerability has been present for nine years, which is an extremely long period of time." The underlying bug was patched this week by the maintainers of the official Linux kernel. Downstream distributors are in the process of releasing updates that incorporate the fix. Red Hat has classified the vulnerability as "important."

This discussion has been archived. No new comments can be posted.

'Most Serious' Linux Privilege-Escalation Bug Ever Is Under Active Exploit

Comments Filter:
  • OMGUbuntu why use linux answered in 3 short words [slashdot.org]

    Why use Linux? Because of security!

    Hmm .. something just doesn't sound right here.

    • Re:Why Use Linux? (Score:5, Insightful)

      by Anonymous Coward on Friday October 21, 2016 @01:49PM (#53124003)

      Why use Linux? Because of security!

      Hmm .. something just doesn't sound right here.
      True. The thing that doesn't sound right is the belief that security is binary. Security is a continuum and sometimes a series of tradeoffs. It's not, never has been, and never will be 100%.

      So no, finding a security bug in the linux kernel doesn't mean that linux is any less secure. We know these things happen. The idea is that it happens LESS often, and with less severity, and with fewer downsides than with Windows.

      • by Anonymous Coward on Friday October 21, 2016 @02:38PM (#53124513)

        For Linux, it's the most serious local privilege escalation ever.

        For Windows, it's Friday.

      • And whenever an article like this comes out, it's almost always already patched on Linux. How often is that the case with the proprietary sphere?

        • "A million eyes makes all bugs shallow."
          Yet again, we see that is total BS. THis exploit has been there for at least nine years, and we see the apologists saying, "When an article like this comes out, it's already patched!!" What about those that have been screwed over by this design flaw for nine years?

          • And I'm saying, what about when a bug shows up on Oracle's or Microsoft's systems, that has been there for 9 years, and they still take a couple months to fix it after it becomes public knowledge?

            Your move, Sparky.

      • Security is binary.
        You're either secure or you're not.
        There's no "less secure" or "more secure".

        The scope/impact of specific vulnerabilities may differ, but the fact that you have vulnerabilities means you're not secure.

        So no, finding a security bug in the linux kernel doesn't mean that linux is any less secure.

        Even if you believe security is a spectrum, you're wrong here. Discovering a previously unknown vulnerability means you know the system to be less secure than you thought it to be.

        • by sjames ( 1099 )

          By your reasoning, security is a fixed steady state of false. Is that safe secure? No, given only 6 months and a modest $100 million investment, it can be drilled through.

        • Another retarded post farted-out without a moment's thought: you're nothing if not consistent. ;)
        • One of the old Roman authors wrote that at any one time, e.g. your slave might slit your throat while in the middle of shaving you.
          I think the message was something like "Deal with it" (in the internet memes sense)

      • And often it depends on the person behind the keyboard. If you have two computers with the same level of security, the computer with the insecure user will get hacked before (and more frequently than) the computer with the more secure user. Unfortunately, user education can only take you so far.

    • Re:Why Use Linux? (Score:4, Insightful)

      by wjcofkc ( 964165 ) on Friday October 21, 2016 @01:57PM (#53124099)
      Why use Linux? Because as much as I love FreeBSD as a hardware barebones headless server for this and that, dealing with hardware driver issues for a fully featured desktop ranges between a pain in the ass and impossible. Otherwise I would be using the PC-BSD variant as a desktop productivity OS over Linux.
      • by dargaud ( 518470 )
        Why ? I mean, as a 99% Linux user for the past 16 years, I've never tried any BSD. I'm not religious about it, I just don't know what would be better on it.
        • by wjcofkc ( 964165 )
          The ports tree is miraculous. It eliminates a lot of admin work you have to deal with in Linux land. It also has a very solid implementation of ZFS, which can be life saving. Also, the layout of the file system is both sane and statically consistent over time. I could carry on for awhile about why I feel it is a superior server OS. Honestly if you don't get it then do your own research on it, contemplate you favorite services and give it a whirl. You will be doing yourself a favor. I assure it is not a reli
    • Re: (Score:3, Insightful)

      by Anonymous Coward

      So, how many security holes just as bad as this one has been silently plugged in Windows the last 15 years? How many equally serious security holes are being exploited in Windows right now? How many worse security holes are being exploited, or waiting to be found in Windows, right now?

      I don't now. But I'm willing to guess the answer isn't "zero" to any of those questions. Nobody ever claimed Linux was bulletproof, the point is that it's better than the alternative.

      Linux is less complex than Windows, bugs te

    • by OzPeter ( 195038 )

      OMGUbuntu why use linux answered in 3 short words [slashdot.org]

      Why use Linux? Because of security!

      Hmm .. something just doesn't sound right here.

      Replying to my own post because I'm defeated by all that whooshing noise from all those other replies.

      Some people just can't take a joke.

  • by Anonymous Coward

    The existing known exploit does not work on stock RHEL5/6 systems because /proc/self/mem is read-only by default. But, there may be other exploit vectors.

    • by Anonymous Coward

      Not sure what rhel5/6 systems you are looking at. All of the ones I checked have it rw.

      • Re: (Score:3, Informative)

        by Anonymous Coward

        "The in the wild exploit we are aware of doesn't work on Red Hat Enterprise Linux 5 and 6 out of the box because on one side of the race it writes to /proc/self/mem, but /proc/self/mem is not writable on Red Hat Enterprise Linux 5 and 6."
        -- https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c13

    • The simple mitigation is to not have local users who will hack your machine.

      If you run a server, an exploit of the server software (nginx, PHP scripts, Ruby on Rails, etc.) will provide local non-root access, which you can then root.

      If you run your server software in Docker, then the host system's binaries aren't exposed. That means an attacker can't modify the disk cache for /bin/su and then su to root; he can only modify the disk cache for /bin/su or glibc from e.g. the debian:jessie image that the D

  • by crow ( 16139 ) on Friday October 21, 2016 @01:45PM (#53123959) Homepage Journal

    Can I use this to root my Android phone? I just want to install an ad-blocking /etc/hosts file, so I don't need a permanent root. This sounds like just the sort of exploit to do the trick, but I haven't looked at the technical details. I just want to do this before the next security update patches it.

    • Re: (Score:2, Informative)

      by Anonymous Coward
      Fuck, you did it. Now APK is going to show up.
    • by Anonymous Coward

      Why don't you use a VPN and do the fingering on the remote end of the VPN, you can even compress the stuff so it loads faster on your end

      • by sirber ( 891722 )
        VPN on android with the compression and encryption is a cpu and battery drain. The best way to block most ads is via /etc/hosts. You still get unity video ads though... then you use lucky patcher :)
    • by Anonymous Coward on Friday October 21, 2016 @02:05PM (#53124169)

      > just want to do this before the next security update patches it

      On your *Android phone*? I don't think you have to worry about that.

    • You could always install the AdblockPlus Browser.

    • If you just want to block ads to your browser, then Firefox has the best tool. uBlock Origin can be configured for adblock, malware, and many sundry lists. Opera also advertises adblock as well as VPN, but Opera is now Chinese-owned and will be able to keybridge you, so caveat emptor.

      You only need to touch /etc/hosts if you want to adblock Chrome and/or something OTHER than a browser. In that case, I am using AdAway from F-Droid, and that needs root every time it applies updates to /etc/hosts, so you will l

  • by Anonymous Coward
  • by account_deleted ( 4530225 ) on Friday October 21, 2016 @02:34PM (#53124463)
    Comment removed based on user account deletion
  • This is a bug in the Linux kernel, affecting most operating systems that use this kernel.
    • This is a bug in the Linux kernel, affecting most operating systems that use this kernel.

      Sorry Richard...

  • by Zo0ok ( 209803 ) on Friday October 21, 2016 @02:57PM (#53124709) Homepage

    I found one of these "exploits in the wild":
    https://github.com/dirtycow/dirtycow.github.io/blob/master/dirtyc0w.c

    It works on the three Linux machines I first tested it on.
    $ dirtyc0w /etc/secretfile.txt abcde
    simply (over)writes abcde to the beginning of the file.

    Fix seems to be available for none of the systems right now.

    At least it requires a local account.... I mean, after all, it must be considered a security problem to allow web users to upload binaries or run arbitrary commands via a web server anyway. But if I was responsible for a students lab with hundreds of Linux computers I would be a little nervous.

    • > Fix seems to be available for none of the systems right now Yeah sure except for ArchLinux, Gentoo and all if I can trust the "News":"Most major Linux distros" And I don't know why nobody mentioned that people running grsec were secure all along, because damn this is the nth major Kernel Exploit that didn't affect them.
      • by Zo0ok ( 209803 )

        For some reason ubuntu installed 4.4.0-45 but insisted on still booting 4.4.0.43. So after a full upgrade and a reboot it was still vulnerable. After I I discovered the problem and booted 4.4.0-45 I confirmed that fixed the problem.

        Raspbian seems not to be fixed (please correct me if I am wrong).

      • Why isn't grsecurity part of the mainline?
  • by CrashNBrn ( 1143981 ) on Friday October 21, 2016 @03:51PM (#53125295)
    S2pidiT Ars Centurion [arstechnica.com] said:

    Linus explained on the GitHub link:

    This is an ancient bug that was actually attempted to be fixed once (badly) by me eleven years ago in commit 4ceb5db9757a ("Fix get_user_pages() race for write access") but that was then undone due to problems on s390 by commit f33ea7f404e5 ("fix get_user_pages bug").

    In the meantime, the s390 situation has long been fixed, and we can now fix it by checking the pte_dirty() bit properly (and do it better). The s390 dirty bit was implemented in abf09bed3cce ("s390/mm: implement software dirty bits") which made it into v3.9. Earlier kernels will have to look at the page state itself.

    Also, the VM has become more scalable, and what used a purely theoretical race back then has become easier to trigger.

    To fix it, we introduce a new internal FOLL_COW flag to mark the "yes, we already did a COW" rather than play racy games with FOLL_WRITE that is very fundamental, and then use the pte dirty flag to validate that the FOLL_COW flag is still valid.

    So there was an attempt to fix the race condition over a decade ago, but it got undone.

  • It's probably the most serious Linux local privilege escalation ever

    The evil twin of Mr. Torvalds has been known to use Please and Thank you, and actively, as well, to wit:

    "Now please, pretty please, with cherry on top, will you take your patch and take it out of my m*****ing kernel??"

    He is working on the anti-kernel, as well, but that has been kept under wraps, until a proper EULA has been prepared.

  • This is an ancient bug [kernel.org] that was actually attempted to be fixed once (badly) by me [Phil "not Paul" Oester] eleven years ago in commit 4ceb5db9757a ("Fix get_user_pages() race for write access") but that was then undone due to problems on s390 by commit f33ea7f404e5 ("fix get_user_pages bug").
    In the meantime, the s390 situation has long been fixed, and we can now fix it by checking the pte_dirty() bit properly (and do it better).
    The s390 dirty bit was implemented in abf09bed3cce ("s390/mm: implement soft

    • Where did you get "It only became a serious flaw recently"? It happened somewhere between 11 years ago and present, but no date is given for commit f33ea7f404e5 (I did try Google).

One man's constant is another man's variable. -- A.J. Perlis

Working...