Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Local Root Hole in Linux Kernels

Posted by michael on Tue Mar 18, 2003 03:09 PM
from the keep-those-users-down dept.
Security Software Linux
xepsilon writes "A local Linux security hole using ptrace has been discovered that allows a potential attacker to gain root privileges. Linux 2.2.25 has been released to correct this security hole, along with a patch for 2.4.20-pre kernels. 2.4.21 ought to contain this fix, once it is released. 2.5 is not believed to be vulnerable to this security hole. See this email from Alan Cox for details, and a patch."
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Local Root Hole in Linux Kernels 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • How is Microsoft responsible? (Score:5, Funny)

    by jmulvey (233344) on Tuesday March 18 2003, @03:12PM (#5538900)
    With all the brainpower on /. I'm sure we can discover a way.

  • Got Root? (Score:5, Funny)

    by FAngel (641209) on Tuesday March 18 2003, @03:12PM (#5538903)
    Got Root?

  • It's Tuesday (Score:5, Funny)

    by Anonymous Coward on Tuesday March 18 2003, @03:13PM (#5538916)
    Journal Entries:

    (looks at watch) its monday again... time to go patch my IIS

    (looks at watch) its tuesday again... time to go patch linux.

  • Could someone post the email up? (Score:3)

    by 00_NOP (559413) on Tuesday March 18 2003, @03:14PM (#5538918)
    It's been /.ed and I'd really like/need to read it asap. Hence I am posting at +2. Karma burning away...

  • patched it already (Score:5, Interesting)

    by Lxy (80823) on Tuesday March 18 2003, @03:15PM (#5538927) Journal
    Got an e-mail this morning from Redhat Network that a new kernel was available to solve this vulnerability. up2date got my machine patched hours before the /. post.

    If you're running Redhat, RHN is a valuable tool that no admin should be without.

    • Re:patched it already (Score:5, Insightful)

      by sporty (27564) on Tuesday March 18 2003, @03:37PM (#5539130) Homepage
      The only reason not to update, is if you haven't QA'd (burn in test) your new kernel. Put int through 100% load tests for 24-48 hours to make sure nothing goes haywire. Last thing you'd want is a strange memory leak causing processes to go bezerk.

      Not to say that you haven't done that, but buyer beware. It makes no diff if it were linux, mac os x , windows, commodore 64. Don't randomly update things. Heck, sometimes us programmers create bugs in programs that are fixed by other bugs existing. Closing one may expose a new one.

      • The Smaller Folks (Score:5, Insightful)

        by DarwinDan (596565) on Tuesday March 18 2003, @05:20PM (#5539976) Homepage
        I second that opinion. However, many sysadmins have a responsibility for public servers (lots of ports open even with a firewall). As such these same sysadmins are smart and have a redundant box to do things like patch a system.

        In addition, some small businesses don't have the luxury of a secondary box or even an IT specialist that can put a machine through a high-load test for more than a few hours at a time -- let alone having to patch it at all!

        Ideally we would all have a RAID 10 array connected to four boxes each running a different OS. While some companies (!) may have the time and money for this, the small folks like mom-and-pop stores can't afford the expense of time or money.

      • Re:patched it already (Score:5, Insightful)

        by caluml (551744) <slashdot&spamgoeshere,calum,org> on Tuesday March 18 2003, @05:58PM (#5540248) Homepage
        I would disagree.

        I much prefer it the way it is. Take Apache/ IIS as examples.
        If you're running 1.3.26, you're safe, and you know it.
        With IIS, if you're running IIS5, but with patch X, and patch y, and patch z applied before patch q, unless you have the MSSql patch r installed in which case you need patch f for IIS, and patch k for MSSql...

        They should do it the other way. Make it simple.
        If you're running IIS 5.0.185 then you're OK. Anything else, and you've got problems.

        Patches and stuff were OK during floppy disk days, and 28.8k modems. I'd much rather not have to worry about incrememental patches.

  • Here's the text of Alans post (minus the .diff) (Score:4, Informative)

    by Mish (50810) on Tuesday March 18 2003, @03:15PM (#5538934)
    Ptrace hole / Linux 2.2.25

    To: linux-kernel@vger.kernel.org
    Subject: Ptrace hole / Linux 2.2.25
    From: Alan Cox
    Date: Mon, 17 Mar 2003 11:04:35 -0500 (EST)
    Sender: linux-kernel-owner@vger.kernel.org

    -----------------------

    Vulnerability: CAN-2003-0127

    The Linux 2.2 and Linux 2.4 kernels have a flaw in ptrace. This hole allows
    local users to obtain full privileges. Remote exploitation of this hole is
    not possible. Linux 2.5 is not believed to be vulnerable.

    Linux 2.2.25 has been released to correct Linux 2.2. It contains no other
    changes. The bug fixes that would have been in 2.2.5pre1 will now appear in
    2.2.26pre1. The patch will apply directly to most older 2.2 releases.

    A patch for Linux 2.4.20/Linux 2.4.21pre is attached. The patch also
    subtly changes the PR_SET_DUMPABLE prctl. We believe this is neccessary and
    that it will not affect any software. The functionality change is specific
    to unusual debugging situations.

    We would like to thank Andrzej Szombierski who found the problem, and
    wrote an initial patch. Seth Arnold cleaned up the 2.2 change. Arjan van
    de Ven and Ben LaHaise identified additional problems with the original
    fix.

    Alan

    • IT'S IN ENGLISH!!! (Score:5, Funny)

      by strredwolf (532) on Tuesday March 18 2003, @03:19PM (#5538965) Homepage Journal
      Haleulia and pass the green beer. It's not in Welsh.

      BTW: If you haven't read, or tried to read, Alan's blog you won't get the joke.

        • Tux is Welsh!!! (Score:5, Funny)

          by schon (31600) on Tuesday March 18 2003, @04:35PM (#5539635) Homepage
          I know "Cymru" means "Welsh" but that's about it.

          Tux, the beloved Linux mascot is Welsh!

          It's true! Tux is a penguin..

          Penguin is derived from two Welsh words: Pen (head) and Gwynn (white)...

          So (besides Alan) there is another link between Wales and Linux.

          (That, and I've tripled your knowledge of the Welsh language :o)

            • Re:IT'S IN ENGLISH!!! (Score:5, Interesting)

              by TheRaven64 (641858) on Tuesday March 18 2003, @05:07PM (#5539855) Homepage Journal
              Welsh has the most glaring deficit of vowels and proper spelling.

              Actually, Welsh has more vowels than English, and is spelt almost entirely phonetically. It's hard for English speakers to read since it uses the same characters to represent different sounds (Yes, I have had to listen to Alan rave about how wonderful Welsh is...). The most confusing thing I find about welsh is the way words 'mutate', that is to say their pronunciation changes depending on the syllable preceding or following them to make the sentence flow more easily.

              It is sometimes useful to know a language that no-one else in the room speaks, and I think that this is one of Alan's reasons for learning, but I prefer Latin for this purpose. The structure is more logical.

  • dead already? (Score:4, Informative)

    by zozzi (576178) on Tuesday March 18 2003, @03:16PM (#5538941)
    Slashdotted already? Try here: here [iu.edu]

  • In other news... (Score:5, Informative)

    by AnriL (657435) on Tuesday March 18 2003, @03:17PM (#5538949)
    And for the hax0rs without a local shell, there's a recent samba instant-remote-r00t vulnerability [samba.org]. Get your patches while they're hot!

  • Love the headline (Score:4, Funny)

    by L. VeGas (580015) on Tuesday March 18 2003, @03:17PM (#5538950) Homepage Journal
    Lo-Cal Root Hole in Linux Kernels

    I think I saw this in an advertisement for granola.

    mmmm... breakfasty

  • FYI, Red Hat Network Advisory (Score:3, Informative)

    by Znonymous Coward (615009) on Tuesday March 18 2003, @03:17PM (#5538951) Journal
    Red Hat Security Advisory

    Synopsis: Updated 2.4 kernel fixes vulnerability
    Advisory ID: RHSA-2003:098-00
    Issue date: 2003-03-17
    Updated on: 2003-03-17
    Product: Red Hat Linux
    Keywords: ptrace
    Cross references:
    Obsoletes: RHSA-2003:025-20 RHBA-2003:069-12
    CVE Names: CAN-2003-0127

    1. Topic:

    Updated kernel packages for Red Hat Linux 7.1, 7.2, 7.3, and 8.0 are now
    available. These packages fix a ptrace-related vulnerability that can
    lead to elevated (root) privileges.

    2. Relevant releases/architectures:

    Red Hat Linux 7.1 - athlon, i386, i586, i686
    Red Hat Linux 7.2 - athlon, i386, i586, i686
    Red Hat Linux 7.3 - athlon, i386, i586, i686
    Red Hat Linux 8.0 - athlon, i386, i586, i686

    3. Problem description:

    The Linux kernel handles the basic functions of the operating system.
    A vulnerability has been found in version 2.4.18 of the kernel. This
    vulnerability makes it possible for local users to gain elevated (root)
    privileges without authorization. This advisory deals with updates to
    Red Hat Linux 7.1, 7.2, 7.3, and 8.0.

    All users of Red Hat Linux 7.1, 7.2, 7.3, and 8.0 should upgrade to
    these errata packages, which contain patches to fix the vulnerability.

    4. Solution:

    Before applying this update, make sure all previously released errata
    relevant to your system have been applied, especially the additional
    packages from RHSA-2002:205 and RHSA-2002:206.

    The procedure for upgrading the kernel manually is documented at:

    http://www.redhat.com/support/docs/howto/kernel- up grade/

    Please read the directions for your architecture carefully before
    proceeding with the kernel upgrade.

    Please note that this update is also available via Red Hat Network. Many
    people find this to be an easier way to apply updates. To use Red Hat
    Network, launch the Red Hat Update Agent with the following command:

    up2date

    This will start an interactive process that will result in the appropriate
    RPMs being upgraded on your system. Note that you need to select the kernel
    explicitly on default configurations of up2date.

  • Hole Found in Linux Server (Score:5, Funny)

    by ch-chuck (9622) on Tuesday March 18 2003, @03:18PM (#5538954) Homepage
    (Server Room, DP) A hole was found in 'cypress', one of the principle Linux file, email and web servers of Brapco Corp early today. "We were dusting out around the back", said Mike Koyro, IT manager of Brapco, "and there it was, right by the power supply." The hole was quickly verified by other members of the IT dept as "really there". Speculation that it may be a screw hole was quickly dispelled when Frank, chief scripting officer, pointed out it didn't have any threads, and no screws were found loose anywhere nearby. "If someone got in here and drilled it during the night, they sure did a clean job - there's no shavings on the floor and the hole has no burrs" observed Mike. "It was either a professional job, with a sharp bit and machining oil, or a manufacturing defect". Calls to Linux Security were unanswered as of press time.

  • Time to patch my IIS^H^H^HKernel (Score:3, Interesting)

    by Richard_at_work (517087) <richardprice.gmail@com> on Tuesday March 18 2003, @03:20PM (#5538975)
    Soooo, i wonder how many posts will appear here along the lines of those in the WebDav exploit story earlier. Not many im willing to bet.

    Those people willing to shout and hollor at every serious issue, screaming bloody murder because someone got it wrong, really pisses me off. Yes people get it wrong, they write insecure code from time to time. This issue and a number of those before it show that Linux has as many opportunities for exploitation as any other OS.

  • Hrm (Score:4, Funny)

    by B3ryllium (571199) on Tuesday March 18 2003, @03:21PM (#5538984) Homepage
    I guess they were just trying to out-do the IIS hole [cert.org].

    Ah well ... there's always "linux single" ... :)

  • ptrace() again? (Score:5, Informative)

    by misof (617420) on Tuesday March 18 2003, @03:22PM (#5538992)

    This is already at least the second problem somehow connected with ptrace() in the kernel. Kernels prior to 2.2.19 were vulnerable to a race-condition attack, that enabled local users to gain root privilegies. This was one of the most "famous" problems in last years and it's known as the execve/ptrace exploit.

    More details:

    This vulnerability exploits a race condition in the 2.2.x Linux kernel within the execve() system call. By predicting the child-process sleep() within execve(), an attacker can use ptrace() or similar mechanisms to subvert control of the child process. If the child process is setuid, the attacker can cause the child process to execute arbitrary code at an elevated privilege. There are also other known lesser security issues with Linux kernels prior to 2.2.19 which have been noted as fixed.

  • To all the windows bashers... (Score:5, Interesting)

    by EZmagz (538905) on Tuesday March 18 2003, @03:29PM (#5539062) Homepage
    Nobody's safe.

    I hate to say it, but this is kind of refreshing. This ins't a troll, so don't get me wrong...I'm a linux user myself. But after seeing the masses rip into MS yesterday when the thread about the IIS 5.0 hole was posted, I got a tad frustrated. Granted, I hate Microsoft as much as the next guy, but this just goes to show you that it's NOT just Microsoft that falls prey to holes and exploits. If it runs an OS, there's a chance it'll be cracked. Simple as that.

    Hell, the linux kernel is without a doubt one of the most audited open source projects out there, and this bug STILL didn't surface until 2.4.20. Of course, I applaud the speed and availibility of patches and workarounds to the bug. Just remember, it happens to everyone.

    • Linux auditing (Score:4, Insightful)

      by Kourino (206616) on Tuesday March 18 2003, @04:38PM (#5539661) Homepage
      I think our friend Al Viro would have something to say about the auditing level of the Linux kernel. And if we're talking about drivers/ in particular, it would probably involve the words "obfuscated", "brain dead", "steaming pile of shit", "warped beyond all belief" ... :)

      Linux code gets a fair amount of review. But once it's there, there really isn't any auditing at all.

    • Re:To all the windows bashers... (Score:4, Insightful)

      by jelle (14827) on Tuesday March 18 2003, @08:50PM (#5541230) Homepage
      Sure, both are security bugs, but of a totally different order of magnitude.

      The IIS hole was a remote exploit including privilege escalation open to abuse by anybody on the Internet, and the kernel one was a local privilege escalation open to abuse by system users with shell access or other capability to run&abuse ptrace(). If you have untrusted local users, you should run them in a UML or vservers/ctx anyway so thay if they escalate privileges, they still can't harm the system.

      Plus, the IIS bug was found after US ARMY web sites [internetwk.com] were getting hacked, and the kernel bug was found by a developer that was auditing/working on part of the code and patch available before any bad guy got to it.

  • Dangit, Slashdot, mirror things like this (Score:5, Insightful)

    by Kiwi (5214) on Tuesday March 18 2003, @03:42PM (#5539180) Homepage Journal
    Dangit, Slashdot, mirror things this important; don't just link to some poor low-traffic Linux kernel archive which can not handle Slashdot-level traffic. I normally don't mind sites being Slashdotted, but a critical security fix being slashdotted is not a good thing.

    Anyway, another copy [iu.edu] of the patch.

    - Sam

  • Simple workaround (Score:5, Informative)

    by volkerdi (9854) on Tuesday March 18 2003, @03:45PM (#5539208)
    If you can't patch this right away, you can easily work around the hole. In order to be vulnerable, you need to have kmod enabled in the kernel, and /proc/sys/kernel/modprobe must contain the name of ANY VALID EXECUTABLE. It doesn't have to be /sbin/modprobe. Even /bin/false is vulnerable on this one.

    To prevent the exploit, give the kernel a bogus filename to use as modprobe, like this:

    cat /this/file/aint/there > /proc/sys/kernel/modprobe

    If you only use kmod to load modules at boot time, you might consider having this run after all your other init scripts, say in rc.local.

    Pat

  • In the meantime... (Score:5, Funny)

    by TheSHAD0W (258774) on Tuesday March 18 2003, @03:59PM (#5539318) Homepage
    Until the patch has been tested and distributed, you can prevent the bug from being exploited by locking the door to your office.

  • Exploitable? (Score:5, Interesting)

    by Rain (5189) <slashdot&t,themuffin,net> on Tuesday March 18 2003, @04:04PM (#5539364) Homepage
    Geez, only took /. 27-odd hours. Anyway.

    I tried writing an exploit for this flaw, but I couldn't get far enough to inject any code. I managed to ptrace(PTRACE_ATTACH, ...) a uid 0 modprobe (easy enough way to call kernel_thread()), but for some reason, the traced process isn't properly reparented, so all subsequent ptrace() calls fail. (Whenever you PTRACE_ATTACH to a process, it's supposed to become the child process of the tracer, and ptrace_check_attach (linux/kernel/ptrace.c) will return -ESRCH if this condition isn't met.)

    I'm not positive this is actually exploitable, but I'm not positive I took the correct approach, either. In any case, the most I've been able to do is spawn a slew of suspended root-owned processes. Not good, but not the end of the world, either. If someone has actually managed to exploit this flaw, I'd love to see some code so that I could see what I did wrong. Conversely, I'm willing to share the code I have upon request. I've only written code up to the current impasse, but once past this problem, the rest should be pretty trivial.

  • Patch won't apply to linux-2.4.20 (Score:5, Informative)

    by sanermind (512885) on Tuesday March 18 2003, @04:16PM (#5539473)
    It fails on include/linux/sched.h with default patch options. Which kind of sucks. You can get it to 'work' by giving patch a fuzz-factor of 3, but then the build fails. Not a very usefull patch.
    cd /usr/src
    mv linux-2.4.20 linux-2.4.20_OLD
    bzcat /otherhome/stor/src/linux/linux-2.4.20.tar.bz2 | tar xv
    cd linux-2.4.20
    patch -p1

    fails at include/linux/sched.h

    If you do 'patch -p1 -F 3' instead, it won't fail, but the fuzz factor obviously leads to a patch error, as the compilation breaks [as soon as include/linux/sched.h is included, BTW]

    I mean, I appreciate knowing that my system is horribly vulnerable, but a WORKING FIX would sure be nice.
  • Everyone's taking comfort in the fact that no remote exploitation is possible, but remember all those universities that you've convinced over the past few years to switch from proprietary UNIX to Linux for their cs department and mail servers? The ones with thousands of local accounts given out to all the students and faculty? Yeah, they might not be happy about this.

  • get over it--your local system isn't secure anyway (Score:5, Insightful)

    by g4dget (579145) on Tuesday March 18 2003, @05:58PM (#5540246)
    Realistically, most regular Linux systems are not secure against local exploits: making a system secure that way is possible, but it's quite a bit of work. You certainly won't get such a system by just doing a [insert your favorite distribution] install. This isn't exactly news either--it's been like that for a long time.

    Of course, it is good that these kinds of bugs get fixed. Some people do run multiuser systems, and it provides an additional barrier against intrusions. But don't lose any sleep over it.

    Incidentally, these kinds of exploits are probably rampant on Windows systems; there, people don't even bother looking for them because there are very few multiuser machines and most people have local Administrator privileges anyway. Also note that Microsoft didn't even try to get Windows certified secure for multiuser use.

    • Re:Stupid question... (Score:5, Informative)

      by Xerithane (13482) <xerithane@@@nerdfarm...org> on Tuesday March 18 2003, @03:36PM (#5539124) Homepage Journal
      Does that mean you have to be at the keyboard, or does that mean you have to have access to the box itself? (a shutdown/restart exploit?)

      This means that you have to already have an existing user account on the system, running in user space. You cannot exploit the box without having (control of) a user account.

      If you are at the keyboard, you can usually get root instantly on Linux. "lilo: linux single"

    • Re:Stupid question... (Score:4, Informative)

      by DarkMan (32280) on Tuesday March 18 2003, @03:44PM (#5539202) Journal
      A remote exploitation means that if your are connected to the internet, (And, in the case of a server deamon, running the affected daemon), then a remote attacker (== only using net acesses) can obtain root privs.

      A local exploit menas that the attacker must be first logged in as a local user (i.e. have a valid account, or have exploited a server daemon to obtain local, unprivildiged access).

      Attacks that require you to have physical acess to the box are generally not classified, as these will always exist (through boot disks, etc), and as thus not audited for.

      It is a common practice to use an insecure deamon to first get local acess, then to use a local root hole, such as this one.

      Hope that helps - the jargon is dense, but useful.

    • Re:Root Kit (Score:5, Informative)

      by Tom7 (102298) on Tuesday March 18 2003, @03:47PM (#5539220) Homepage Journal
      No, but a good bet is to reinstall MD5-verified binaries of netstat and ps, and then look for suspicious processes or network servers. All of the rootkits I've seen work by running a hidden background process, or by modifying the kernel -- and you're replacing the kernel, so that should be ok.

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.