Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Security Software Linux

Local Root Hole in Linux Kernels 503

Posted by michael from the keep-those-users-down dept.
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."
This discussion has been archived. No new comments can be posted.

Local Root Hole in Linux Kernels More

Local Root Hole in Linux Kernels

Comments Filter:

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

    by jmulvey ( 233344 ) on Tuesday March 18, 2003 @04: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 @04:12PM (#5538903)
    Got Root?

  • Eek! (Score:2, Interesting)

    by Jouster ( 144775 )
    And please, allow me to be the first to say:

    Holy shit, this could be a problem.

    Excuse me while I go patch my servers, which all of my developers have user-level access to, albeit very limited access.

    New marketing ploy for TMF: get your security news before the 13-year-old 5<R1p7 <1|)|)135, since they don't have credit cards with which to subscribe.

    Jouster

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

    by Anonymous Coward on Tuesday March 18, 2003 @04: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 @04:14PM (#5538918) Homepage
    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 @04: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.
    • It's also been fixed in slackware-current, which became 9.0 just a few hours ago :-)

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

      by sporty ( 27564 ) on Tuesday March 18, 2003 @04: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 @06: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.

    • And the difference between this and setting Windows Update to download automaticlly then inform you before proceeding with an install is? Basically all that has been proved is a good admin will stay on top of updates. And eveyone here gets confused when something isn't Microsofts fault.

      • Re:patched it already (Score:3, Informative)

        by Lxy ( 80823 )
        There is one difference: who do you trust?

        I trust Redhat not to slip spyware and weird license agreements into the kernel I'm downloading. I trust that it's an honest to God GPL'd kernel. Why? Because I'm a trusting person, and I haven't had any freakish incidents with Redhat.

        I don't trust Microsoft. I don't want code with God knows what hacked in with a license agreement that takes away my first born while installing.

        While I'm on the subject, I received an e-mail from Microsoft before I recieved the

    • Re:patched it already (Score:3, Interesting)

      by DrXym ( 126579 )
      It would be even more invaluable if Red Hat et al made RPM and their updates incremental. It is rather silly to expect people on 56k modems (of which there are still many) to download 30-50mb of patches to fix what probably amounts to 1mb at most of code changes. Kernel changes are particularly horrible - a one line patch means 35Mb download! How many users will bother with that? Now perhaps that's their own fault when they're rooted, but it's bad for everyone else too - a rooted box is a springboard for fu

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

        by caluml ( 551744 ) <slashdot@spamgoe ... minus herbivore> on Tuesday March 18, 2003 @06: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.

        • Re:patched it already (Score:3, Interesting)

          by DrXym ( 126579 )
          I didn't mean that way. I mean if up2date says there is a new version e.g. 1.2.1 and you have 1.2.0, and there is an incremental diff available (i.e. 1.2.0-1.2.1) then it should fetch and apply that rather than fetching the whole 1.2.1 package which could be massive. After patching you now have 1.2.1 as if you had done rpm -Uvh on it.

          There is no 'hotfixing' or piece patching here. The result of the incremental diff is the same as installing the whole new version, just considerably easier to download. As

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

    by Mish ( 50810 ) on Tuesday March 18, 2003 @04: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 @04: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.
      • Speaking of green...
        It was saint paddy's day yesterday, so I wonder how in the hell Mr. Cox could nail a bug today...
        I know I couldn't do something like that the day after...
        • "saint paddy's day" is for the Irish you moron. Cox is Welsh.
          • Like the welsh doesn't use any excuse to get drunk?
            Come one grow up! Anybody that knows about st. paddy uses it as an excuse to get smashed on a monday!

          • Huh? (Score:3, Funny)

            by FireballFreddy ( 472710 )
            St. Patrick's Day, a perfectly valid and socially acceptable excuse to get rip-roaring pissed, and you say it's *only* for the Irish? I'm sorry, please hand in your geek membership card. You aren't allowed to post here anymore.

  • dead already? (Score:4, Informative)

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

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

    by AnriL ( 657435 ) on Tuesday March 18, 2003 @04: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 @04: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 @04: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 @04: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 ) on Tuesday March 18, 2003 @04: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.
    • lol
      Too bad this was only exploitable locally. Any secure server would not have local access available to users. I have to agree, but not as a zealot. Bugs will happen but Linux development seems to have them patched instantly, whereas Microsoft's ploy is play dumb until the patch is released, and then act like they did it overnight.
    • 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.

      I hate when I choose to reply instead of mod

      • Re:I'm not going to patch. (Score:5, Insightful)

        by siteTHREE ( 636369 ) on Tuesday March 18, 2003 @04:44PM (#5539190) Homepage
        Have you considered the possibility of someone exploiting a non-root remote hole on your box and now having the ability to escalate themselves to root?

        • Re:I'm not going to patch. (Score:4, Funny)

          by gosand ( 234100 ) on Tuesday March 18, 2003 @05:38PM (#5539655)
          Have you considered the possibility of someone exploiting a non-root remote hole on your box and now having the ability to escalate themselves to root?

          Well, I, ahhh....

          Shut up!

          Would someone please mod my previous post down as "fingers faster than brain"?
          Thank you.

        • Have you considered the possibility of someone exploiting a non-root remote hole on your box and now having the ability to escalate themselves to root?

          EVERYBODY plays the odds:

          FIRST: a user has to exploit *A* remote exploit. Which one? Could be anything. Most exploits are either popular services, or shots in the dark. Patch the popular services, and you've defeated 90% of the scans. Remember, there's safety in numbers, and the vast amount of hosts on the internet just makes it less likely you'll

    • The default configuration of URLScan prevents the WebDAV vulnerability from being exploited. URLScan is a part of the IIS Lockdown tool. For more information about URLScan, visit the following Microsoft Web site: http://www.microsoft.com/technet/security/URLScan. asp
    • Surely there's a world of difference between a hole that's remotely exploitable and one that can only be exploited by a local user. Web servers, mail servers (properly configured as 'black boxes'), firewalls, routers etc are all unlikely to be affected if the only user account is actually root).

      Then we have timescale - the BBC are reporting here [bbc.co.uk] that the US Army were caught out by the Microsoft hole as much as 2 weeks ago, yet a patch didn't turn up until now. Here we have a patch before any known exploi

  • Hrm (Score:4, Funny)

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

    Ah well ... there's always "linux single" ... :)
  • Are there any know exploits for this yet? Has anyone scene this in practice?

    Rus
    • 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.

      It isn't a remote exploit. Anyone who is foolish enough to attempt to h4X0r your b0X0rz with this vulnerability is within the normal attack range of a LART [bofh.net].

      Please, do patch any affected machines you have as soon as possible, but don't *ahem* panic.

      Soko

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

    by misof ( 617420 ) on Tuesday March 18, 2003 @04: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 @04: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 @05: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 @09: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.

  • "Remote exploitation of this hole is
    not possible."

    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?)

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

      by Xerithane ( 13482 ) <xerithane.nerdfarm@org> on Tuesday March 18, 2003 @04: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 @04: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.
  • Once the patch is installed, is there any way I can be sure my system hasn't been rootkitted without doing a clean install?

    Jason
    ProfQuotes [profquotes.com]

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

      by Tom7 ( 102298 ) on Tuesday March 18, 2003 @04: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.
    • is there any way I can be sure my system hasn't been rootkitted without doing a clean install?

      No. Absolutely not.

      You could check for specific rootkits which leave traces behind, but there is no way to find arbitrary rootkits.

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

      by GT_Alias ( 551463 )
      ChkRootKit [chkrootkit.org] will check for the known ones and some of the obvious signs for one.

      Doesn't help much though if the user has developed something of their own that flies below the radar. Chkrootkit doesn't hurt for a bit of peace of mind.

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

    by Kiwi ( 5214 ) on Tuesday March 18, 2003 @04: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 @04: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

    • Re:Simple workaround (Score:3, Informative)

      by volkerdi ( 9854 )
      cat /this/file/aint/there > /proc/sys/kernel/modprobe

      Oops... While the above also happens to work, what I meant was more like this:

      echo "/this/file/aint/there" > /proc/sys/kernel/modprobe

      Pat
  • Will Ximian's red-carpet patch this?

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

    by TheSHAD0W ( 258774 ) on Tuesday March 18, 2003 @04: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. t h e m u ffin.net> on Tuesday March 18, 2003 @05: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 @05: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.

  • this could be a big problem (Score:5, Insightful)

    by Trepidity ( 597 ) <[gro.hsikcah] [ta] [todhsals-muiriled]> on Tuesday March 18, 2003 @06:04PM (#5539833)
    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.

    • UNIX to Linux switch (Score:3, Insightful)

      by aksansai ( 56788 )
      Never forget that proprietary, commercial UNIX solutions are also vulnerable to kernel-level bugs and exploits. I used to work for a university that deployed Linux and Solaris solutions - the patch sets for Solaris (kernel and userland utilities) were just as necessary as the Linux server installations.

      The beauty of the Linux and open-source worlds is that the code is available right before your very eyes and is subject to scrutiny, day-in and day-out. Commercial offerings are not available to the genera

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

    by g4dget ( 579145 ) on Tuesday March 18, 2003 @06: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.

  • This and IIS exploit (Score:3, Interesting)

    by OoSync ( 444928 ) <wellsed.gmail@com> on Tuesday March 18, 2003 @07:37PM (#5540501)
    While its not really kosher to bash an OS because of a single flaw, there is a fundamental difference in the case of this flaw and the previously announced IIS exploit: this one's not yet exploited. One thing that hurts FS/OSS on bug lists is that all *potential* exploits in open code will be listed as bugs, while many proprietary producst only disclose known, possibly exploited, bugs. Case in point, the IIS problem was exploited almost a week ago. The kernel problem was noticed, fixed, and no exploit exists. In fact, a previous poster on this board has posted his inability to trigger the *potential* exploit and asked for help.

  • Clean patch against 2.4.20 (Score:3, Informative)

    by bahamat ( 187909 ) on Tuesday March 18, 2003 @08:46PM (#5540878) Homepage

    This is probably way too late in the discussion to get seen, but Alan's patch won't apply cleanly to 2.4.20.



    A clean patch can be found here:

    http://www.hardrock.org/kernel/2.4.20/linux-2.4.20 -ptrace.patch [hardrock.org]



    Sorry if you get /.ed.

Slashdot Top Deals

"Ninety percent of baseball is half mental." -- Yogi Berra

Close