Announcement

Collapse
No announcement yet.

A 0-Day Local Privilege Escalation Bug Hits The Linux Kernel

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • A 0-Day Local Privilege Escalation Bug Hits The Linux Kernel

    Phoronix: A 0-Day Local Privilege Escalation Bug Hits The Linux Kernel

    CVE-2016-0728 is being made public today: a 0-day local privilege escalation vulnerability in the Linux kernel that's been present now for over three years...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Hm...

    Code:
    [I]Linux PowerStation 4.4.0-gentoo #4 SMP Wed Jan 13 10:50:34 CET 2016 x86_64 Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz GenuineIntel GNU/Linux[/I]
    No SElinux, no nothing. Just "strong" stack protection in-kernel (I guess irrelevant here), yet exploit does not work.

    Ubuntu 14.04 and 16.04-a1 seem to be secure, too...
    Last edited by Pyth0n; 19 January 2016, 10:34 AM.

    Comment


    • #3
      How do you know it does not work? Mine stuck forever in Increfing... phase

      Comment


      • #4
        Originally posted by Pyth0n View Post
        Hm...

        Code:
        [I]Linux PowerStation 4.4.0-gentoo #4 SMP Wed Jan 13 10:50:34 CET 2016 x86_64 Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz GenuineIntel GNU/Linux[/I]
        No SElinux, no nothing. Just "strong" stack protection in-kernel (I guess irrelevant here), yet exploit does not work.

        Ubuntu 14.04 and 16.04-a1 seem to be secure, too...

        You may have SMEP/SMAP enabled on your CPU that prevent this particular exploit from working properly (although a different attack program might be able to bypass those protections).

        Comment


        • #5
          Did you make sure to
          grep -e "commit_cred" /boot/System.map-*
          grep -e "prepare_kernel_cred" /boot/System.map-*
          or the equivalent with /proc/kallsyms and edit the #define'd addresses before trying this exploit? Seems like an important part of the recipe.

          Besides this exploit requires 2^32 system calls, which should plausibly take several minutes.
          Last edited by Idonotexist; 19 January 2016, 10:59 AM.

          Comment


          • #6
            This is awful.

            Comment


            • #7
              And the funny thing is? The guilty line is a fucking GOTO.
              Everyone using this atrocious coding practice should be shot in the head.

              Comment


              • #8
                Does this mean good news for those trying to root there android phone?

                Comment


                • #9
                  Originally posted by magika View Post
                  And the funny thing is? The guilty line is a fucking GOTO.
                  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 within the struct (object) and had function pointers (methods); both of which allowed this to be an exploitable bug. In OO languages these are implemented in the language/interpreter/compiler and usually done right.

                  Comment


                  • #10
                    Originally posted by Techwolf View Post
                    Does this mean good news for those trying to root there android phone?
                    Probably, yeah, though I don't know why Android's SELinux implementation isn't stopping this...
                    All opinions are my own not those of my employer if you know who they are.

                    Comment

                    Working...
                    X