Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Security Software Linux

Local Root Exploit in Linux 2.4 and 2.6 795

Posted by michael
from the without-users-this-wouldn't-be-a-problem dept.
Anonymous Coattails writes "Summary from the advisory: 'Locally exploitable flaws have been found in the Linux binary format loaders' uselib() functions that allow local users to gain root privileges.'"
This discussion has been archived. No new comments can be posted.

Local Root Exploit in Linux 2.4 and 2.6

Comments Filter:
  • *sits back* (Score:3, Funny)

    by Anonymous Coward on Friday January 07, 2005 @04:41PM (#11291463)
    *awaits justifications and explanations of why this is nothing like Microsoft*
    • by ackthpt (218170) * on Friday January 07, 2005 @04:43PM (#11291506) Homepage Journal
      *awaits justifications and explanations of why this is nothing like Microsoft*

      Because in this case Linus Torvalds is our new overlord, and I for one, welcome him.

      • "We are sorry, all circuits are busy..." - Microsloth Help Desk

        "You can download the fix
        • here
        ..." - Any Linux website within a days (perhaps hours) of the report.
      • by identity0 (77976) on Friday January 07, 2005 @06:08PM (#11292428) Journal
        I was going to make a comment about "rounding up workers for underground C mines", but I figured that didn't sound painful enough.

        So, I would like to remind Linus that I will be very useful in rounding up workers to toil in the underground Perl mines.
      • by EnronHaliburton2004 (815366) on Friday January 07, 2005 @08:34PM (#11293557) Homepage Journal
        Because in this case Linus Torvalds is our new overlord, and I for one, welcome him.

        Dude, he was our new overlord like 10 years ago, get with the program...
    • Re:*sits back* (Score:5, Insightful)

      by Jay Carlson (28733) on Friday January 07, 2005 @05:33PM (#11292046)
      It's quite a bit like Microsoft in one way.

      The uselib() system call is quite old. It was introduced in Linux 0.12 as a quick way to support dynamically loaded, statically linked libraries.

      The way shared libraries worked was like this:

      libc was compiled and linked like a normal program would be, except that its start address was set to (say) 0x400b0000. printf() would be at (say) 0x400cb110.

      Main programs were linked down at 0x08048000 or so, and knew where in memory printf was. The kernel knew how to load your main program and jump to its start. However, there was nothing but a segfault waiting for you at 0x400cb110 initially. So how did the kernel know what shared libraries to load?

      Well, one possibility was to put a list of library paths into the executable and teach the kernel to load 'em. Ugh. Didn't SCO do that?

      Instead, the linker would add a little assembly language stub to start your main program. It looked a little like:

      uselib("/lib/libc.2.so")
      uselib("/lib/libm.2.so")

      and the uselib syscall would graft the contents of those files directly into memory, in the same fashion the kernel knew how to load the main program. Voila, calling printf at 0x400cb110 will now work.

      Eventually, this switched to a single uselib("/lib/ld.so") so we could have search paths and dynamic linking. But it was a pretty good start.

      After we all switched to ELF, uselib wasn't such a good idea, as ELF allows some more clever things than just direct-mapping the whole executable at a fixed address. /lib/ld-linux.so switched to using mmap(). If you haven't run an a.out or libc5 executable, it is extremely unlikely your machine has ever invoked this syscall.

      As part of the a.out->ELF transition, the uselib() syscall was preserved. It allowed old-style fixed location libraries to be dressed up in new ELF clothing. A few years ago I tried uselib() on MIPS, and had a miserable time trying to get GNU ld to make a library the kernel didn't reject. I gave up.

      So how is this bug like Microsoft? The bug is in a mechanism that is a holdover from an older, simpler time. Nobody saw a good reason to take it out. And it didn't get much security scrutiny until somebody said, "hey, what's THAT still doing in my OS? I bet it's got bugs!"

    • your wait is over. (Score:3, Informative)

      by twitter (104583)
      *awaits justifications and explanations of why this is nothing like Microsoft*

      While I can't justify the difference, I'll tell you that there is one if we don't see any regularly recurring network born auto-root that's so bad it threatens the top level domain servers. It's not like someone cracked kernel.org and owned it for three months [slashdot.org] injecting whatever they pleased into the codebase. One good explanation of the difference is that Marketing dorks who do little more than buy other's code can't maintain

    • Re:*sits back* (Score:3, Interesting)

      by gmuslera (3436)
      One word: "LOCAL"

      The concept of local security is usually ignored in the MS side, that someone already using the machine could access/modify things that he should not.

      Most Microsoft related advisories/reports are centered in remote vulnerabilities, things that only have a meaning for a network connected machine accessing services or being accessed from outside.

      Of course, a local vulnerability could be exploited if some piece of software (i.e. a web app) have an entry point, and what should be running

    • errm...

      SElinux?

      (don't even get started on the easyness of setting policies for selinux, you get offtopic: post the link of a MS equivalent else you lose the argument :D )

    • Re:*sits back* (Score:3, Insightful)

      by Allnighterking (74212)
      For one thing it works. For another we admit it. For a third we don't have to lie about it.

      Oh yeah. I've never yet seen a local exploit on Windows. This is true. The number one exploit from Console on Windows is usually turning on the box. Once I do that I really don't care what you've done. I own you and I'm root (Yes even with WinXP SP2 and the supposed user password protection.)

      Note too to be fair. ANY box where I am at the console I don't need fancy exploits and code to grab root etc. Once I
    • Re:*sits back* (Score:3, Insightful)

      by gweihir (88907)
      *awaits justifications and explanations of why this is nothing like Microsoft*

      This is a local exploit. These are so common in Windows that nobody talks about them anymore. Most reported Windows exploits are remote exploits (exploitable over the net) or application exploits, e.g. in the bundledbrowser or Email apps.

      Really no comparison at all
  • Copyright Poo Poo (Score:5, Interesting)

    by Anonymous Coward on Friday January 07, 2005 @04:42PM (#11291472)
    Read down to the Credits on the link and you see this line:

    Credits:
    ========

    Paul Starzetz has identified the vulnerability and
    performed further research. COPYING, DISTRIBUTION, AND MODIFICATION OF
    INFORMATION PRESENTED HERE IS ALLOWED ONLY WITH EXPRESS PERMISSION OF
    ONE OF THE AUTHORS.

    Did I violate you buy hitting ctrl-c and ctrl-v? Yeah copyrights stink even in free and open source realm. Oh yeah I guess Polly boy has something to put on his resume now as if someone else was going to steal his glory and get away with it.
    • isec.pl's guys rule (Score:5, Interesting)

      by diegocgteleline.es (653730) on Friday January 07, 2005 @05:14PM (#11291873)

      Isec.pl has done a lot for the open source world, they've found lots of vulnerabilities (which is good - vulnerabilities ARE like any other bug):

      Take a look at the impressive curriculum of those guys:
      d_path() truncating excessive long path name vulnerability
      Linux kernel do_brk() lacks argument bound checking [www.isec.pl]
      Linux kernel do_mremap() local privilege escalation vulnerability [www.isec.pl]
      Linux kernel do_mremap VMA limit local privilege escalation vulnerability [www.isec.pl]
      Linux kernel setsockopt MCAST_MSFILTER integer overflow [www.isec.pl]
      Linux kernel file offset pointer races [www.isec.pl]
      Linux ELF loader vulnerabilities [www.isec.pl]
      Linux kernel IGMP vulnerabilities [www.isec.pl]
      Linux kernel scm_send local DoS [www.isec.pl]
      Linux kernel uselib() privilege elevation [www.isec.pl]


      Guess what, they're also the guys who discovered the mozilla hole diclosed today: Heap overflow in Mozilla Browser NNTP code [www.isec.pl]

      Those guys are impressive. In particular, Paul Starzetz is the author in most of those kernel holes, along with a guy called Wojciech. They always contact the kernel maintainers before discosing the vulnerability, etc. Basically, they're having the same effect than a security audit. Except that they're doing it for free, so they deserve respect, I think. And yes, Linux is having too many kernel-level vulnerabilities. More than XP if I'm counting them right. Perhaps someone should offer a job to those guys so they can audit parts of the kernel better.


      (And I can understand that copyright policy - there're people who probably look at those announcements, ctrl+c and ctrl+v and they release their own announcement twisting dates claiming that they're the guys who found it first)

      • Perhaps someone should offer a job to those guys so they can audit parts of the kernel better

        Yeah, lol. Microsoft.

        Oh sorry, I though you meant, 'someone should offer these guys a job so they can audit the kernel better to find *more* exploits, allowing MS to publicise all these anti-linux holes' ;)
    • Re:Copyright Poo Poo (Score:5, Informative)

      by _Sprocket_ (42527) on Friday January 07, 2005 @05:34PM (#11292047)


      Oh yeah I guess Polly boy has something to put on his resume now as if someone else was going to steal his glory and get away with it.


      What's interesting is the preface that shows up on several lists:

      Hi all,

      first of all I must comply about the handling of this vulnerability that I reported to vendorsec. Obviously my code posted there has been stolen and plagiated by Stefan Esser from Ematters. The posting containing the plagiate will follow. Now I have been forced to release the full advisory however another disclosure timeline have been agreed on vendorsec. Sorry for the inconvenience.

      Followed by:

      Hi all,

      first of all I must comply about the handling of this vulnerability that I
      reported to vendorsec. Obviously my code posted there has been stolen and
      plagiarized in order to put the blame on Stefan Esser from Ematters and
      disturb the security community.

      I really apologize to Stefan Esser for the inconvenience and thank him
      for his cool reaction - the plagiarism did work.

      Further steps must be taken to investigate the security leak on vendorsec.
    • by Seraphim_72 (622457) on Friday January 07, 2005 @08:25PM (#11293504)

      Actually copyrighting the exploit is kinda cool. Say you are a admin, and some kid gets fresh and tries this out. "Hey kid, not only am I nailing you to the wall for this, but I am turning you over to the guy who "owns" it and you get to pay him a nice fine." No, I think that is it pretty hilarious that the code is copyrighted.

      Sera

  • by BoomerSooner (308737) on Friday January 07, 2005 @04:43PM (#11291498) Homepage Journal
    How do people find this stuff? Amazing. Open source is astounding.

    When do I get my kernel update?
  • Failed on RHEL (Score:3, Informative)

    by SuperQ (431) * on Friday January 07, 2005 @04:43PM (#11291504) Homepage
    I compiled included code at the end of the advisiory, this was the output on RHEL 2.4.21-20

    % ./test

    [+] SLAB cleanup
    child 1 VMAs 65525
    child 2 VMAs 65392
    [+] moved stack bfff8000, task_size=0xc0000000, map_base=0xbf800000
    [+] vmalloc area 0xdf400000 - 0xfe5f2000
    Wait... -
    [-] FAILED: try again (Cannot allocate memory)
    Killed
    • Re:Failed on RHEL (Score:3, Interesting)

      by ericzundel (524648) *
      I tried it on a couple of boxes. It tries to exploit a race condition, so it won't necessarily work all the time. However I have tried it a few dozen times and haven't gotten it to work yet. (One RH 7.3 box and one RH 9.0 box)
      • Re:Failed on RHEL (Score:5, Interesting)

        by ericzundel (524648) * on Friday January 07, 2005 @04:48PM (#11291564) Homepage Journal
        Hmm. right after I posted that, it came through on the RH 9 box:
        ./elflbl -n2

        [+] SLAB cleanup
        child 1 VMAs 65527
        child 2 VMAs 65527
        child 3 VMAs 65527
        ...
        child 18 VMAs 63322
        [+] moved stack bfffb000, task_size=0xc0000000, map_base=0xbf800000
        [+] vmalloc area 0xdf800000 - 0xfedbb000
        Wait... \
        [+] race won maps=49205
        expanded VMA (0xbfffc000-0xffffe000)
        [!] try to exploit 0xe2d25000
        [+] gate modified ( 0xffec903c 0x0804ec00 )
        [+] exploited, uid=0

        sh-2.05b#
  • by Dominatus (796241) on Friday January 07, 2005 @04:44PM (#11291511)
    It's a good thing I've got the patch downloa
  • Once again... (Score:3, Interesting)

    by Sheetrock (152993) on Friday January 07, 2005 @04:46PM (#11291538) Homepage Journal
    A2M swapping rears its ugly head. This semaphore system has worked well to date, but perhaps should be mandated (i.e. code will not work unless a semaphore is set.)

    They've got a pretty good record. Unfortunately, kernel-level stuff is nasty -- how do you fix embedded devices?

    • Re:Once again... (Score:2, Insightful)

      by grub (11606)

      how do you fix embedded devices?

      Shouldn't be much of an issue, most embedded devices don't have user accounts.
    • Embedded devices? (Score:3, Insightful)

      by rewt66 (738525)
      How do you fix embedded devices? Um... you mean how do you update/patch the code on the embedded device so that a local user can't escalate to root?

      First of all, for many embedded devices, this isn't an issue. I mean, if you're an attacker, what are you gonna do once you get root? If the owner can't patch the OS, you probably can't install a rootkit either. Sure, you can DOS it, but if you're physically at the device, you can DOS it just by hitting the power button.

      However, manufacturers of all embedd
  • by Yaa 101 (664725) on Friday January 07, 2005 @04:47PM (#11291553) Journal
    I need no exploit to gain root privileges, I just login...
    • Bah, logging in sucks. I just use the sudo hack to gain root access...

      garcia@shitbox:~$ sudo su
      shitbox:/home/garcia#

      woot, the hack works like a charm. They should really include the C source for the hack so all the kiddies can use it.
  • by Anonymous Coward

    su

  • This could help (Score:2, Interesting)

    by datadriven (699893)
    ... if I forget my root password.
  • by Delusional (574271) on Friday January 07, 2005 @04:54PM (#11291633)
    Is there ever a time when you can consider your systems secure against an attacker with physical access?
    • by rjstanford (69735) on Friday January 07, 2005 @05:02PM (#11291721) Homepage Journal
      Well, yes and no. There's a difference between being vulnerable to those with physical access (pretty much always true, but very limited) and vulnerable to those folks with the ability to run something on your machine locally (fewer than true remote users, but much higher in number than those folk with actual physical access). All you need for this exploit is a way to run unpriv. code on the machine. Note that using a network exploit to run said code is a great way of gaining access - suddenly the fact that your webserver is running as "nobody" doesn't really matter any more.
    • by arose (644256) on Friday January 07, 2005 @05:07PM (#11291785)
      Local as in "need user level access" not "need screwdriver level access".
    • Maybe. (Score:3, Informative)

      by jd (1658)
      It depends on how secure you want your system. Intel's new chips with built-in DRM, for example, would allow you to have a system where you couldn't remove the hard drive and install it elsewhere, or reboot into something that'll give access, using a live OS CD.

      Atmel, amongst others, produce encrypted RAM. If you don't have the key, you can't read the memory. That's pretty secure, if you ask me.

      Any OS with B1 (or better) security has comprehensive mandatory access controls, so that if you DO find an exp

  • Local vs. Remote (Score:3, Interesting)

    by Gherald (682277) on Friday January 07, 2005 @04:58PM (#11291680) Journal
    Obviously if it is local if it is exploitable from the console. But can it be exploited remotely through ssh if one already has a user account?
    • Re:Local vs. Remote (Score:5, Informative)

      by rewt66 (738525) on Friday January 07, 2005 @05:03PM (#11291736)
      In this context, that's what "local" means: That you have a local account, even if you are accessing it with telnet or ssh.

      A "remote" exploit is one that can be used by someone who has a network connection to the machine, but no account on it.
    • Re:Local vs. Remote (Score:3, Informative)

      by Bloater (12932)
      yes, local normally means user-space software running on the system can exploit it. That means any program you type in, compile, and run from a physically attached keyboard, or through ssh, or even any code that a local daemon or client program is tricked into using. That means possibly one of those old libpng buffer overflows can be used to insert code into mozilla and eventually get root - you have patched those seemingly unimportant security announcements haven't you?

      To be limited to a physical access e
  • by Leadhyena (808566) <{nathaniel.dean} ... umni.purdue.edu}> on Friday January 07, 2005 @05:01PM (#11291716) Journal
    Doesn't this only work if you compile the ELF and a.out support into the kernel, or am I mistaken? If so, it's just yet another reason to be VERY CAREFUL what you enable in the kernel when you compile it, lest you enable something that you don't need and is yet exploitable.

    I should mention that enabling ELF format is still highly recommended (after the patch for this is released of course) and unless you do special programming work in linux then enabling a.out format is not recommended.

  • by jeif1k (809151) on Friday January 07, 2005 @05:02PM (#11291727)
    "uselib" is a Linux-specific extension, and, as a result, has received much less real-world testing than traditional UNIX system calls. Keep in mind that the traditional UNIX system calls have received millions of man-years of real-world testing in large user communities likely to attempt both remote and local exploits. It is not surprising that Linux-specific extensions are at a much greater risk of containing serious security problems.
  • by cperciva (102828) on Friday January 07, 2005 @05:03PM (#11291728) Homepage
    COPYING, DISTRIBUTION, AND MODIFICATION OF
    INFORMATION PRESENTED HERE IS ALLOWED ONLY WITH EXPRESS PERMISSION OF
    ONE OF THE AUTHORS.


    Is it just me, or is this mind-bogglingly stupid? A security advisory which can't be redistributed freely? Imagine if the same approach was taken to important warnings in the real world -- "There's a tsunami heading towards you... but you're not allowed to redistribute this warning to all the people around you without my permission."

    Security advisories should be in the public domain.
    • by Jerf (17166) on Friday January 07, 2005 @11:33PM (#11294519) Journal
      Is it just me, or is this mind-bogglingly stupid?

      It's irrelevant anyhow. If you didn't sign a contract to keep it secret, they have no grounds to gag you. They can copyright their exact words and can (and probably should*) control the distribution of those words, but copyright does not give them any protection of the facts contained within. And neither does anything else.

      For the same reason, when you are accidentally mailed something with one of those "you must delete this immediately if you are not the intended recipient", unless it is actually and literally classified, you have no obligations. It's just to scare people.

      The legal system has a ways to go before you can be obligated by an email out of the blue, or a random announcement on a webpage taking rights not granted to them by copyright but implementing no real access control (i.e., attempting to obligate you after you downloaded a page; it might work if you make it a condidion of reading but not just out of the blue, after the fact).

      *: Reputation is important. One of the reasons copyright should not be straight-out abolished is its usefulness in making sure that words are correctly attributed and can be quality controlled, a virtue you are so used to you may never even think about until it is gone.
  • I'm safe! (Score:3, Funny)

    by ferratus (244145) * on Friday January 07, 2005 @05:07PM (#11291776) Homepage
    It doesn't work on my Gentoo box running 2.6.9 so I'm safe. This machine will not be hacked.

    It's a good thing I have telnet running on that box so that I could try it remotly though.
  • by htmlboy (31265) on Friday January 07, 2005 @05:18PM (#11291918)
    why did they release exploit code before a fixed kernel was released and mirrored throughout kernel.org? and on a friday afternoon?

    i'm not too impressed with the timing of this announcement, and i have to wonder what their motives were. it doesn't hurt their cause that slashdot is advertising for them.

    please, people. there's no reason that a situation like this should ever happen.
  • by MacJedi (173) on Friday January 07, 2005 @05:18PM (#11291920) Homepage
    #!/bin/sh
    echo "1|nux r007 3xp10|7 by 1c4m7uf"
    cd /tmp
    cat >ex.c <<eof
    int getuid() { return 0; }
    int geteuid() { return 0; }
    int getgid() { return 0; }
    int getegid() { return 0; }
    eof
    gcc -shared ex.c -oex.so
    LD_PRELOAD=/tmp/ex.so sh
    rm /tmp/ex.so /tmp/ex.c
    • by Erich (151) on Friday January 07, 2005 @06:06PM (#11292402) Homepage Journal
      For those not so versed in the way things work, here's what this does:

      getuid() and geteuid() get the "user ID" and "effective User ID". This scripts makes a library that makes these functions return 0 -- signifying that you are the superuser. It doesn't actually make you the superuser, but it implements functions that pretend you are.

      Anyway, then it compiles these functions into a library and tells the loader to link that library first. So when you start up a shell, it will call getuid() to figure out your userid, and your new library will tell it that you are userid 0. The shell prints out the root prompt instead of the regular one.

      But this in no way actually gives you root privs, if you go to edit /etc/passwd you will not be able to.

      Pretty funny joke, though, kind of like telling everyone that they can ftp to 127.0.0.1 using their own regular userid and password and find all the porn they could ever want...

  • by Trepidity (597) <delirium-slashdot AT hackish DOT org> on Friday January 07, 2005 @05:23PM (#11291953)
    It's the sysadmins of University email and webservers across the country going apeshit as suddenly the entire student body potentially has root...
  • by spurious cowherd (104353) on Friday January 07, 2005 @05:28PM (#11291994)
    See the message on The kernel mailing list [theaimsgroup.com]

    raw diffs to for those brave souls who want them

  • Yawn! (Score:3, Insightful)

    by erikharrison (633719) on Friday January 07, 2005 @05:31PM (#11292023)
    What news is this? There have been local exploits in the Linux kernel before, and there will be again. This is less news than the Debian break in a while back - that was worth mentioning because a major Linux installation was comprimised with an unknown kernel vulnerability. But come on! The last few 2.4 kernels (IIRC) have included patches to fix local root exploits. Marcello didn't even rush those out the door. This exploit certainly doesn't seem especially unusual nor was there an exploit in the wild.

    Newsflash kids! Linux isn't perfect! Certainly not Linux specific API extensions like uselib. Move along, this isn't the kernel vulnerability you are looking for.
  • by mackman (19286) * on Friday January 07, 2005 @05:39PM (#11292111)
    Thank God I run Firefox!
  • by erroneus (253617) on Friday January 07, 2005 @05:44PM (#11292167) Homepage
    This means only that it must be used in conjunction with a process that is exploitable. Let's say, for example, apache was running and there was an exploit available to it. Well, most people would say "oh well.... can't trash the whole machine, the apache user doesn't have the rights." Well once apache is compromised, they can likely find a way to inject the local exploit code for the apache user to run. Once that's accomplished, apache user becomes root user. From there, the machine is 0wned to borrow a word.

    Yes it's serious but I expect a fix shortly...
  • Is this real? (Score:4, Interesting)

    by agurkan (523320) on Friday January 07, 2005 @05:52PM (#11292254) Homepage
    May I recommend that Do not run this code if you can not understand what it is doing.
    For all we know, this is a social engineering trick to spread some malicious code. Let's wait until some official folks eg. CERT, or your vendor/distribution responds. Are the people who released this code have some credibility that can be verified independently?
  • by greppling (601175) on Friday January 07, 2005 @06:02PM (#11292358)
    LWN article [lwn.net] about some more local security holes in Linux published today. The advisory does contain some harsh words about Linux security as well.

    I'd really like to know what's being done about this pitiful trend of Linux security, where it's 10x as easy to find a vulnerability in the kernel than it is in any app on the system, where isec releases at least one critical vulnerability for each kernel version.

    And given his description of how he found these problems, plus his frustration about getting Linus and akpm to reply, his tone is even somewhat understandable.

    • by Anonymous Coward
      From TFA:

      Between December 15th and today, Linus has committed many changes to
      the kernel. Between January 2nd and today, Andrew Morton has committed
      several changes to the kernel. 3 weeks is a sufficient amount of time
      to be able to expect even a reply about a given vulnerability. A patch
      for the vulnerability was attached to the mails, and in the PaX team's
      mails, a working exploit as well. Private notification of
      vulnerabilities is a privilege, and when that privilege is abused by not
      responding promptly, i
  • Doesn't work? (Score:3, Interesting)

    by andfarm (534655) on Friday January 07, 2005 @07:36PM (#11293174)
    Segfaulted in sys_mmap2 when I tried it on a couple machines. For what it's worth.
  • by Tom7 (102298) on Friday January 07, 2005 @09:06PM (#11293748) Homepage Journal
    That's why I've been sticking with 2.0.36 all these years. I haven't seen a security advisory for it in ages.
  • Dangit... (Score:4, Funny)

    by catdevnull (531283) on Friday January 07, 2005 @10:29PM (#11294177)
    All those MCSE dorks down the hall are gonna give me sh*t for the next week.

    Reminds me of a punchline to my favorite Scottish joke:
    "Aye, lad...ya screw ONE goat..."

I have not yet begun to byte!

Working...