Forgot your password?
typodupeerror
Security Linux

Exploits Emerge For Linux Privilege Escalation Flaw 176

Posted by samzenpus
from the protect-ya-neck dept.
angry tapir writes "Linux vendors are rushing to patch a privilege escalation vulnerability in the Linux kernel that can be exploited by local attackers to gain root access on the system. The vulnerability, which is identified as CVE-2012-0056, was discovered by Jüri Aedla and is caused by a failure of the Linux kernel to properly restrict access to the '/proc//mem' file."
This discussion has been archived. No new comments can be posted.

Exploits Emerge For Linux Privilege Escalation Flaw

Comments Filter:
  • Awesome that this will lead to easier root access on Android devices.
    On the flip side I'm sure Android vendors won't get around to patching this for a while and our devices will be vulnerable.

    Now, off to patch my Linux boxen.

    • by toadlife (301863)

      this will lead to easier root access on Android devices

      When I saw the headline that's exactly what popped into my head; "one-click" root tools for various Android devices that don't currently have any.

    • by JAlexoi (1085785)
      Except that only version 4.0 is vulnerable. And only GNex and Nexus S have that version deployed by.... Google! So I see an update pretty soon.
    • by bfree (113420) on Wednesday January 25, 2012 @08:32PM (#38824513)
      Really? This bug was only present in kernel releases 2.6.39 and newer. Do any Android devices use kernel's based on a Linux this current? A quick search says Android 2.3. used 2.6.35 and 3.0 used 2.6.36 so the number of devices this might possibly help you root looks miniscule.
      • by NeoMorphy (576507) on Wednesday January 25, 2012 @08:53PM (#38824643)

        Really? This bug was only present in kernel releases 2.6.39 and newer. Do any Android devices use kernel's based on a Linux this current? A quick search says Android 2.3. used 2.6.35 and 3.0 used 2.6.36 so the number of devices this might possibly help you root looks miniscule.

        I am replying with my new Asus Transformer Prime, which is running ICS(Android version 4.03), kernel is 2.6.39.4.

        I'm thinking this bug is God's way of saying "You are loved. Now go forth and exploit your tablet!"

    • by slack_justyb (862874) on Wednesday January 25, 2012 @11:57PM (#38825545)
      Someone has already beaten every one else to the punch. [github.com]

      However, you need Ice Cream Sandwich and you will need access to a disassembler. Also, you cannot use this exploit for "one-click" root access as the only program that is in the Android stack that runs setuid root, is run-as. That command is statically linked so you will still need adb access so that you can disassemble the program to find it's exit call.

      So there is still a fair amount of work left to be done to make this an exploit that can be used in the "wild" for Android devices. However, as a fair note. A little crowd sourcing to compile a list of offsets for different devices could greatly speed up the process. I'm actually curious if Google will patch this in there kernel.
    • by crutchy (1949900)

      our devices will be vulnerable

      only if you're dumb enough to install apps like "HotNakdChyX" from "WeRHaXorZ" that require every permission possible

      • If your browser/flash player/some other legit app has a zero day that allows the execution or arbitrary code you are just as screwed as if you install a malicious app.

        • by crutchy (1949900)
          If you're using flash then you're already dumb by default, along with anyone who enables Java in their browser.

          Javascript could be a possible vector, but seems like a bit of a long shot.

          I think the majority of malware development on Andriod is probably focused on the ignorance of users just installing apps that require ridiculous permissions. If the user wants an app/game enough, they are likely to accept whatever permission it says it needs regardless of whether it actually needs them or not.

          Secur
          • by crutchy (1949900)
            an even better security measure would be to allow the user to prevent access to a certain permission, while still allowing the app to think it has that permission (call it "permission spoofing"). that way if the app doesn't really need the permission, it will work just fine without it. worst case is the app stops working and you have to restart (or uninstall) it.
          • You are almost right. Sadly, some of us need flash and java to do our jobs. F*** You Cisco!

  • Hrrm (Score:5, Insightful)

    by Anonymous Coward on Wednesday January 25, 2012 @05:51PM (#38823337)

    If someone is in a position to run a local exploit, aren't you pretty much fucked anyways?

    • Re:Hrrm (Score:4, Insightful)

      by JimCanuck (2474366) on Wednesday January 25, 2012 @05:56PM (#38823373)
      Yes that you are.
    • Re:Hrrm (Score:5, Insightful)

      by MichaelSmith (789609) on Wednesday January 25, 2012 @05:56PM (#38823375) Homepage Journal

      Web servers are vulnerable because they run server side code, often uploaded with vulnerable content management systems, etc.

    • by EvanED (569694)

      Right, because no organization would give their employees user access to a machine but not root.

    • Re: (Score:2, Insightful)

      Of course. The best local exploit is a screwdriver and a spare moment or two.

      Some quick contrarian rules:

      Rule #1: There is no such thing as 100% secure. Even 100% bug-free cannot be considered 100% secure. It may work according to the design, and the design can be 100% correct today, but today is not tomorrow.

      Rule #2: The more complicated layers of security you add, the more security holes you add. For those into car analogies, security always ends up being bolted on, like bondo dent filler, becau

      • Re:Hrrm (Score:5, Informative)

        by Anonymous Coward on Wednesday January 25, 2012 @06:41PM (#38823747)
        I was with you up until Rule #3 which is nonsense.
        • Really? Try proving it's "nonsense". .

          It's not "nonsense" for physical security, for hashed passwords, one-time pads, or for biometric security (and biometric is the biggest joke of all). Given enough knowledge and physical access, ALL security can be defeated, either by gaining access or denying the recipient access, or both.

          • by Zero__Kelvin (151819) on Wednesday January 25, 2012 @08:32PM (#38824509) Homepage

            All security is ultimately "security through obscurity."

            "I was with you up until Rule #3 which is nonsense."

            Really? Try proving it's "nonsense". .

            You either don't know what the word all means, or you don't know what the term security through obscurity means.

            • You either don't know what the word all means, or you don't know what the term security through obscurity means.

              It could be worse. He might not know about or, either.

      • Re:Hrrm (Score:5, Interesting)

        by Mad Merlin (837387) on Wednesday January 25, 2012 @06:47PM (#38823787) Homepage

        Rule #1: There is no such thing as 100% secure. Even 100% bug-free cannot be considered 100% secure.

        There's also no such thing as 100% bug-free.

        Rule #3: All security is ultimately "security through obscurity."

        While in the strictest sense, this may not be untrue, to phrase it that way is extremely dishonest. An encryption algorithm that relies on the secrecy of the algorithm is totally worthless (security by obscurity), whereas an encryption algorithm that relies on the secrecy of the keys used for encryption is quite useful (not security by obscurity in the normal sense).

        In fact, if you want to be pedantic about it, the relevant definition for obscure is...

        not readily understood or clearly expressed; also : mysterious [1]

        Which is about understanding and not so much about knowledge. I may understand that I need a username and password to log into your system, just because I don't know what the username or password is doesn't make it security by obscurity. In fact, say I wanted to break into your house, I may have seen you use a physical key to open the front door and walk in and I may have even memorized the pattern of teeth on the key, but it does me no good if I don't have a key of my own to open the door with. There is certainly no obscurity in that security.

        If you're going to go ahead and say that all security is "security through obscurity", then you may as well make the next logical step of not implementing any of it.

        [1] http://www.merriam-webster.com/dictionary/obscure [merriam-webster.com]

        • Your "contrary example" actually proves my point.

          In fact, say I wanted to break into your house, I may have seen you use a physical key to open the front door and walk in and I may have even memorized the pattern of teeth on the key, but it does me no good if I don't have a key of my own to open the door with. There is certainly no obscurity in that security.

          Once you have the pattern, you no longer need a key of your own - you just go and get one manufactured. Or you take a blank and you file it down.

          • by Zero__Kelvin (151819) on Wednesday January 25, 2012 @08:37PM (#38824553) Homepage
            Again, you don't know what security through obscurity [wikipedia.org] means. If the access to the code or other design that implements the security breaks it, then that is security through obscurity. All security relies on a secret known by one party, but unknown to others. This has absolutely nothing to do with security by obscurity.
          • Your "contrary example" actually proves my point.

            In fact, say I wanted to break into your house, I may have seen you use a physical key to open the front door and walk in and I may have even memorized the pattern of teeth on the key, but it does me no good if I don't have a key of my own to open the door with. There is certainly no obscurity in that security.

            Once you have the pattern, you no longer need a key of your own - you just go and get one manufactured.

            You contradict yourself. If you didn't need a key why would you go get one made? Furthermore, what ceases to be obscured through the process of taking your knowledge of the key's teeth and having a replica made? (Hint: nothing)

            • The fact is that keys only work when the pin lengths are not known. You can also open a lock without the key (or any key) - just search for MIT Guide to Lock Picking.
              • Re:Hrrm (Score:4, Interesting)

                by anonymov (1768712) on Wednesday January 25, 2012 @10:45PM (#38825241)

                "The fact is private encryption keys only work when P and Q are not known. You can also decrypt the cyphertext without the key - just search for $5 wrench"

                You're mistaking "secret", which is necessary part of every encryption scheme, with "obscurity", which is useful only in very specific circumstances.

                Following your analogy, security by obscurity is making key duplication method secret and hiding the lock's inner working. Good security, on the other hand, is when you can't duplicate the key unless you snatch it from the owner and can't pick the lock even if you know how it's built.

                Security by obscurity is useful only as preliminary defense line to stall an attacker until he gathers enough information about your systems to begin targeted attack.

                • As you yourself admit in your closing remark:

                  Security by obscurity is useful only as preliminary defense line to stall an attacker until he gathers enough information about your systems to begin targeted attack.

                  ... once I know enough about your system, you have a problem. If I know, for example, the hashing algorithm, I can begin a slow attack using rainbow tables targeting that hash size/characteristics, going from the most likely to the least likely characters. I don't even need to come up with YOUR p

        • by NeoMorphy (576507)

          There's also no such thing as 100% bug-free.

          What kind of attitude is that? /bin/true on Solaris looks bug free to me.

    • by LingNoi (1066278)

      I could see a few ways to do it..

      - Linux games are becoming more popular
      - A poorly coded script on a webserver that lets you upload and execute a file

    • by xaoslaad (590527)
      Attacks come from inside too. Disgruntled user, or even just a dev or curious individual who read an article and decided to go try it. Shell and bastion servers are a reality for some.
    • by drolli (522659)

      so i gather we just forget about any access control and everybody is root?

    • by evilviper (135110)

      If someone is in a position to run a local exploit, aren't you pretty much fucked anyways?

      No. "Multiuser system" indicates users are secure from one another. Linux is not ms-dos. I'm sure vmware would like you to believe otherwise.

      Network services use multiuser system access controls to good effect. Bind, ntp, etc., will chroot themselves into a nearly empty dir, and then drop privledges. This means an exploit in, say, bind results in attackers only getting a non-privledged account access on the targe

  • It'll be fixed tomorrow
  • Start programming, Linus!

  • Link to more info (Score:5, Informative)

    by milbournosphere (1273186) on Wednesday January 25, 2012 @06:15PM (#38823511)
    It's a geekier breakdown, but is quite informative.

    http://blog.zx2c4.com/749

    Gets into the memory specifics of the bug. I found it to be far better than the actual article.

    • by c++0xFF (1758032)

      Thank you! I was browsing through Linus's patch and couldn't make heads or tails of it.

      That and I couldn't help noticing that he got rid of a bunch of goto statements while he was at it. At least these gotos were actually used for error handling...

  • by Trogre (513942) on Wednesday January 25, 2012 @06:43PM (#38823769) Homepage

    Since this bug was introduced in Linux 2.6.39 Debian Stable (squeeze, Linux 2.6.32) is not affected. Unstable(sid, Linux 3.1) has already been patched, though Testing (wheezy) is still vulnerable.

    More information here [debian.org]

    • I've been looking around but haven't found any information on when the fix might migrate into Testing. Any idea?

  • Simple explanation (Score:5, Informative)

    by Chemisor (97276) on Wednesday January 25, 2012 @07:49PM (#38824241)

    There is /proc/pid/mem, a pseudofile referring to the memory of process pid. It has 0600 permissions so you can't write to the memory of other users' processes. The bug occurs when you exec an suid executable and the kernel does not change open fds for /proc/pid/mem. This way, you can open mem, dup it to stderr, and exec su with a garbage parameter. su will duly print an error, quoting the offending parameter, writing to its process memory. With a properly selected shellcode you can get root.

  • /dev/kmem and 4.2 BSD spy program batman!
  • What'd "//" be ? (Score:5, Informative)

    by aglider (2435074) on Thursday January 26, 2012 @02:48AM (#38826219) Homepage

    /proc//mem

    is the very wrong quotation!
    The original source [techworld.com.au] quotes instead:

    /proc/<pid>/mem

    which is the memory as seen by a certain process whose PID is <pid>.
    Moreover, there's no "/proc/mem" file and the "//" whould be interpreted as "/".
    But maybe that'd be just the Slashdot editor.

    • by mx+b (2078162)
      I think /. simply ate the greater-than and less-than signs and everything in between, thinking it was an html tag.
  • What programs depend on it to be writeable? Just make the file read-only for the PID owner.

Moneyliness is next to Godliness. -- Andries van Dam

Working...