Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Bug Software Security Linux

New Linux Kernel Vulnerability 486

Posted by CmdrTaco from the well-thats-just-not-pleasant dept.
Stop Or I'll Noop writes "Paul Starzetz writes, "A critical security vulnerability has been found in the Linux kernel memory management code inside the mremap(2) system call due to missing function return value check. This bug is completely unrelated to the mremap bug disclosed on 05-01-2003 except concerning the same internal kernel function code." Full scoop here." Update: 03/07 20:53 GMT by T : This vulnerability (and fixes) were mentioned briefly in an update to this earlier posting.
This discussion has been archived. No new comments can be posted.

New Linux Kernel Vulnerability More

New Linux Kernel Vulnerability

Comments Filter:

  • Many eyes, but wide open or tight shut ? (Score:5, Insightful)

    by Space cowboy ( 13680 ) * on Sunday March 07, 2004 @11:23AM (#8490972) Journal
    I'm not sure whether this is a triumph of the distributed nature of the kernel, or a catastrophic failure of the whole model... The mremap() code was presumably
    looked at in great depth just recently, after a critical vulnerability was found. A few weeks go by and another hugely important hole is found...


    Since no special privileges are required to use the mremap(2) system call any
    process may use its unexpected behavior to disrupt the kernel memory management
    subsystem.

    Proper exploitation of this vulnerability leads to local privilege escalation
    giving an attacker full super-user privileges. The vulnerability may also lead
    to a denial-of-service attack on the available system memory.


    Now I know the consequences of a problem bear little relation to its root cause, but I am a little surprised at how this managed to find its way through all these eyes looking at the offending code a week or so ago. Actually making it work as a security hole looks to be reasonably complex, (which may be why it wasn't found, I guess), but if one piece of code can have 2 major vulnerabilities in as many weeks, maybe it's time to start worrying about when Linux *does* take over the desktop...

    I thought the automated 'Stanford Checker' (sp ?) was ideal for this sort of problem ? (Where the returned value from a function is ignored...) Perhaps it was flagged up but took some in-depth analysis for the kernel developers to realise it really was a problem...

    So, is this a master-stroke of the development model, with various people around the world all individually checking code and Hey! Someone found something, or is it a "failure" where all those people missed it the first time around, and it's a pure fluke it was found now.... I'm still not sure, but I'll give the benefit of the doubt to the model - hey, it's been fixed! :-)

    Simon

    • Re:Many eyes, but wide open or tight shut ? (Score:5, Insightful)

      by whig ( 6869 ) * on Sunday March 07, 2004 @11:28AM (#8491005) Homepage Journal
      I'd be more inclined to call this a demonstration of the successful "many-eyes" approach. The latest mremap() vulnerability took only a few weeks to be discovered, and the folks publishing it are "eyes" that have alerted kernel developers to the problem.

      • Re:Many eyes, but wide open or tight shut ? (Score:5, Insightful)

        by H4x0r Jim Duggan ( 757476 ) on Sunday March 07, 2004 @11:44AM (#8491142) Homepage Journal
        Yeh, but if you read the security report, this problem exists in *all* 2.2, 2.4, and 2.6 Linux's - so this local exploit has been sitting there for ~5 years before The Good Guys spotted it.

        That's a long time. Maybe some crackers have been using this exploit during that time (or, of course, maybe they haven't).

        • Re:Many eyes, but wide open or tight shut ? (Score:5, Informative)

          by hobbesmaster ( 592205 ) on Sunday March 07, 2004 @11:59AM (#8491228)
          Erm, the problem is that this is a local exploit, not a remote one. I doubt that very many crackers have been using this exploit, because you have to have a local account in the first place to do it.

          • eyes wide stupid? (Score:5, Insightful)

            by EvilAlien ( 133134 ) on Sunday March 07, 2004 @12:08PM (#8491278) Journal
            The only thing separating local exploits from remote in impact is the cracker finding a way to get unpriviledged access to the host. Lots of remote but "trivial" exploits are discovered, and sysadmins like to write those off as unimportant if they don't involve priv escalation... and with the next breath, write off all local-only priv escalation vulns.

            You may trust your authorized users, but do you trust their passwords, habits in storing passwords ("You don't expect me to remember that, do you? Where are my post-it notes..."), and wisdom to not extend trust to ANYONE?

            Do you also trust users to not run a piece of malicious code that shows up purporting to be some groovy new Linux app that will do some groovy new thing? Afterall, it would only have to require a vanilla user account... and Linux never gets viruses, so why worry? ;)

            I think you see where I'm going with this. Local exploits need to be patched too, and sysadmins all too frequently think they don't because they are "only local".

            • Re:eyes wide stupid? (Score:5, Insightful)

              by Anonymous Coward on Sunday March 07, 2004 @01:07PM (#8491569)
              Exactly. In the real world, remote rooting in one step might earn style points, but as a general rule, it just doesn't happen that often. It can be hard work keeping everything patched up to the nines, but if your company has ever called in a (good) pen testing team, you will have experienced first hand how a chain of seemingly 'trivial' vulnerabilities (including for e.g. escalating to the 'games' group) can result in the compromise of most of your most important assets.

              Sysadmins who trivialize these 'moot' issues should realize that at some point, if not today, maybe next year, they are going to have to defend their judgement to an angry CEO who has just lost big money. I don't believe 'total security', even at the software can be attained. All we can do is to keep on patching, and to disclose these vulnerabilities in a responsible and efficient manner.

            • judicial use of 'noexec' (Score:4, Insightful)

              by Anonymous Coward on Sunday March 07, 2004 @03:07PM (#8492244)
              this is why anywhere unpriviledged users can write (/home, /var, /tmp, etc.) should be on a partition mounted 'noexec'. If a cracker can get local access, but not execute their own code, they are limited as to what they can do. This is also another good use of chroot, although the BSD 'jail' is a more robust solution.

            • Re:eyes wide stupid? (Score:5, Funny)

              by Anonymous Coward on Sunday March 07, 2004 @05:20PM (#8493032)
              simply disable all local user accounts.

              I really dont understand what all the fuss is about.

          • Re:Many eyes, but wide open or tight shut ? (Score:5, Insightful)

            by BlowChunx ( 168122 ) on Sunday March 07, 2004 @12:15PM (#8491313)
            From the article: Proper exploitation of this vulnerability leads to local privilege escalation giving an attacker full super-user privileges.

            Now, I am not a hacker, but I think after I got local access via another exploit, I would use this current vulnerability to get root, install my back door/zombie code, etc. and leave quietly.

            Every exploit is serious.
          • Quite a few virtual hosting companies run on linux, and UML is popular for virtual servers. $5 a month could get you a local account on a linux box with a good net connection.
        • Yeh, but if you read the security report, this problem exists in *all* 2.2, 2.4, and 2.6 Linux's - so this local exploit has been sitting there for ~5 years before The Good Guys spotted it.

          So basically this proves that Linux is just as insecure as Windows is. There have been lots of major kernel vulnerabilities floating around in the past 6 months. I guess it's time to switch to OpenBSD.

        • this local exploit has been sitting there for ~5 years before The Good Guys spotted it.

          Well, I think this proves that the "security through obscurity" model is, at best, ineffective. If it has been so long there for anyone to see and the "good" guys didn't see it, what makes you believe that the "bad" guys would spot it?

          I don't have hard data to prove this, but I believe that the following two points are true: (1) there are more good guys than bad guys, or otherwise society as we know it wouldn't exist;

          • Way Too Idealistic (Score:4, Interesting)

            by EventHorizon ( 41772 ) on Sunday March 07, 2004 @03:08PM (#8492250)
            That's a very naive, idealistic argument. American business often maximizes shareholder value by being as dishonest as possible, short of clearly breaking commonly enforced laws. Under your argument, Darl McBride is a "good guy" because he's a) rich from the SCOX pump-n-dump and b) not in jail (yet).

            Anyway, go read "The Art Of War" or watch "The Godfather". It is a serious error to assume your enemy is weak, and I would recommend against that philosophy when securing critical assets.

          • Enough already ... Obscurity has its place (Score:5, Insightful)

            by duck_prime ( 585628 ) on Sunday March 07, 2004 @03:10PM (#8492263)
            this local exploit has been sitting there for ~5 years before The Good Guys spotted it.

            Well, I think this proves that the "security through obscurity" model is, at best, ineffective. If it has been so long there for anyone to see and the "good" guys didn't see it, what makes you believe that the "bad" guys would spot it?
            Well jeez, this actually sounds like an argument *for* security through obscurity. If it took so long to find the bug even with open source access, imagine how long it would have taken to find the exploit in a closed-source product.

            Don't forget ... security through obscurity (S.T.O) is not in itself a bad thing. If you don't know what you're looking for, you're unlikely to find it. The real problem with S.T.O. is that if you are relying solely on it, it is a 'brittle' defence: once an attacker is aware of the 'hidden secret' it's game over.

            So ... do you use a password on your accounts? After all, that's security through obscurity, right?
    • In my humble opinion, it's an unavoidable part of making software. We have to be realistic: closed or open source, as a program gets more and more complex, more elaborate bugs come out, and some of them turn out to be exploitable. Having strict coding guidelines can help, having lots of eyes looking at the code helps, but ninja vulnerabilities will still stealth through.

      My thinking is that Linux on the desktop is going to need a contingency plan for a widespread vulerability, similar to what Microsoft does with Automatic Updates. I know it's not perfect, but I'll be damned if I can think of anything better. It's nice to think you can make a bullet-proof kernel, but also naive.

      • Re:Many eyes, but wide open or tight shut ? (Score:5, Informative)

        by BiggerIsBetter ( 682164 ) on Sunday March 07, 2004 @12:12PM (#8491303)

        My thinking is that Linux on the desktop is going to need a contingency plan for a widespread vulerability, similar to what Microsoft does with Automatic Updates.

        I'm guessing you don't use Linux then. All major distros release such updates very quickly, and RedHat at least had a desktop icon that alerted users if updates were available. The kernel will get patched if it needs to, but it's up to the distro vendors to include something "idiot proof" to yell if the system needs an update.

      • Automatic Update? Put the following into your crontab at an interval of your choosing:

        On Debian/Red Hat with APT:
        apt-get update && apt-get dist-upgrade

        On Red Hat with up2date:
        up2date -u

        On Mandrake:
        urpmi.update && urpmi --auto-select

        And so on.. Now obviously these could be imrpoved (i.e. mail the admin if it fails), but auto-updating is a lot easier under Linux.

    • Re:Many eyes, but wide open or tight shut ? (Score:5, Informative)

      by spitzak ( 4019 ) on Sunday March 07, 2004 @12:36PM (#8491392) Homepage
      If your eyes were a little wider open you would see that this is NOT A NEW BUG! In fact it is the exact same one (the *second* in mremap(), not the third) as reported in a Slashdot article well over a month ago.

      I actually read the bug report then, and I read it now, and when I got down to the bug explanation (with the lines of X's representing memory) I realized it was the exact same one I had seen before!

  • A lot of problems in mremap... (Score:5, Insightful)

    by LucidityZero ( 602202 ) <sometimesitsalex@@@gmail...com> on Sunday March 07, 2004 @11:25AM (#8490987) Homepage
    Wasn't there a (third) problem with mremap back around summertime too? These all sound like barebones, common mistakes. Who is contributing this source? Was it all the same person? Maybe we should be checking his/her code a bit more closely!

  • Install windows! (Score:4, Funny)

    by Compunerd ( 107084 ) on Sunday March 07, 2004 @11:25AM (#8490990) Homepage
    Get windows CD
    Boot
    Install

    bah

  • Damn (Score:4, Insightful)

    by Broken_Windows ( 658461 ) on Sunday March 07, 2004 @11:26AM (#8490993) Homepage
    I really did not want to spend my Sunday patching kernels.

    • Re:Damn (all your base are belong to us) (Score:5, Informative)

      by kompiluj ( 677438 ) on Sunday March 07, 2004 @11:30AM (#8491022)
      Oh really? I am running 2.4.25 on my all systems for two weeks already - since the first advisory. Patch or be patched.

    • Re:Damn (Score:5, Funny)

      by Anonymous Coward on Sunday March 07, 2004 @11:35AM (#8491065)
      Don't bother. There's no published exploit. Have a beer. Watch the game. Don't worry. Relax. What's your IP?

    • Re:Damn (Score:2, Funny)

      by Tremanhil ( 246867 )
      So turn off your PC, pop a bag of Kettle Corn or Pop Secret into the microwave and spend part of your Sunday popping kernals... and the rest watching movies.

      And patch your kernel another day.
    • If you'd have kept up to the latest stable, you wouldn't have this problem.
    • Hmm, is this available via Yum repositories? One of my suprises was that this utility installs new kernels for me automagically. On the down side, my network card module breaks ( so far ) every time I boot to the new kernel that Yum installed. But I think I can live with recompiling the NIC module now and then.

  • dupe (Score:5, Insightful)

    by Feyr ( 449684 ) * on Sunday March 07, 2004 @11:27AM (#8490999) Journal
    huu dupe? that thing was released over a week ago!

  • Not a new vulnerability (Score:5, Informative)

    by Anonymous Coward on Sunday March 07, 2004 @11:27AM (#8491003)
    This is the same vulderability that was disclosed a few weeks ago. The advisory was updated on March 1st to include exploit code.

  • I'm guessing that we can expect a patch from SCO? (Score:4, Funny)

    by rivaldufus ( 634820 ) on Sunday March 07, 2004 @11:27AM (#8491004)
    After all, if they can expect people to license Linux from them, they should be providing support.

  • Does this mean... (Score:3, Funny)

    by mcx101 ( 724235 ) on Sunday March 07, 2004 @11:28AM (#8491009)

    ...I'm going to have to patch the kernels on the Debian servers and reboot again?

    That'll be the third time in as many months.

  • Well, as they say... (Score:2, Funny)

    by Anonymous Coward
    In Linux it's a bug...

    In Windows it's a feature.

  • Amazing what a one line oversight can do (Score:5, Insightful)

    by Anonymous Coward on Sunday March 07, 2004 @11:30AM (#8491016)
    Just compare the time and effort putting together the 3 page write up on the bug to the cost of reviewing and fixing the code in question when it was originally written. I believe the study that found that once the bug leaves the development shop to go to consumers it costs $9000 per line to fix. It's as true in open source as it is for closed source.
    • As long as it isn't YOUR $9,000.... ;)

    • Re:Amazing what a one line oversight can do (Score:5, Insightful)

      by cperciva ( 102828 ) on Sunday March 07, 2004 @12:34PM (#8491385) Homepage
      I believe the study that found that once the bug leaves the development shop to go to consumers it costs $9000 per line to fix.

      That figure depends largely upon how many customers you have and how sophisticated your patch-distribution system is. In pre-internet days, a critical problem might have meant shipping a floppy disk to each of your customers (of course, this reduced the chance of problems being classified as "critical"). Now, most security problems in FreeBSD can be fixed in two minutes using 50kB of bandwidth and binary patches [daemonology.net]. Most operating systems fall somewhere in the middle, distributing entire [apple.com] files [microsoft.com], or even complete [redhat.com] packages [debian.org], every time a one-line security fix is necessary, with the effect of requiring a 50-fold (or more, in the case of packages) increase in bandwidth (and, over slow connections, time).

      Someone from Microsoft explained this to me as "we've got huge amounts of bandwidth, so we really don't need to save bandwidth by using patches"... it doesn't surprise me that Microsoft ignores the fact that delta compression would benefit their customers, but I expected better from Apple or the Linux community.

  • Can someone quickly fix this ? (Score:5, Funny)

    by Anonymous Coward on Sunday March 07, 2004 @11:30AM (#8491020)
    So we can get back to bitching about Window's security flaws :D

  • Not a big deal really (Score:5, Informative)

    by jmoen ( 169557 ) <jarand.moen@gmai ... m minus caffeine> on Sunday March 07, 2004 @11:31AM (#8491030)
    Seems like none of the current releases are affected by this anyway. Ref. the article:
    Only version: 2.2 up to and including 2.2.25, 2.4 up to to and including 2.4.24, 2.6 up to to and including 2.6.2

    -jmoen-

  • "Windows users: want Security, install linux"??? (Score:5, Funny)

    by Padrino121 ( 320846 ) on Sunday March 07, 2004 @11:31AM (#8491032)
    Slowly but surely as Linux is getting more mainstream it seems the same kind of holes that perpetually plague Windows exist in Linux as well.

    It might be time to take a page from the MS book and take a few weeks for a full line by line audit.

  • Somewhere . . . (Score:5, Funny)

    by Prince Vegeta SSJ4 ( 718736 ) on Sunday March 07, 2004 @11:32AM (#8491035)
    A Giddy Billionaire is scheming:

    Kernel 2.6.4-rc2-bk3: Never, I'll Never turn to the Dark side, I'm open source...like my father before me.

    Bill: So be it, open source

    Bill: if you will not be turned, you will be destroyed (shooting purple lightning bolts)

    Bill: You will pay the price for your lack of vision

    Kernel 2.6.4-rc2-bk3: Linus please (in agony).

    .....to be continued

    I await my -5 (Troll)

  • From the link... (Score:3, Informative)

    by Spoing ( 152917 ) on Sunday March 07, 2004 @11:32AM (#8491040) Homepage
    1. Synopsis: Linux kernel do_mremap VMA limit local privilege escalation vulnerability

    Local, not remote.

    In general: If an attacker has local access or can gain the equivelent by using a remote access tool, a local exploit can be a problem.

    So, personally I'm not too worried though others with different types of users or configurations might have a high level of concern.

  • Old news (Score:5, Informative)

    by phaze3000 ( 204500 ) on Sunday March 07, 2004 @11:34AM (#8491053) Homepage
    This is why 2.6.3 was released, as discussed in this [slashdot.org] slashdot story from the 18th of Feb. The date on the linked article is March 1 - this is a second document on the same vulnerability that gives more details. It was not released at the time to give people a chance to patch.

  • known since 18. feb. 2004 (Score:5, Informative)

    by gst ( 76126 ) on Sunday March 07, 2004 @11:34AM (#8491058) Homepage
    actually this vulnerability was announced on 18. feb. 2004 by isec (see http://lwn.net/Articles/71682/).

    isec just waited some weeks until they released the exploit...
  • Could someone please say what this vulnerability is in English? That article made my head hurt.

    • Re:Laymens terms? (Score:5, Funny)

      by WWWWolf ( 2428 ) <wwwwolf@iki.fi> on Sunday March 07, 2004 @11:50AM (#8491172) Homepage

      Sure. A program can ask the operating system kernel to Do Things. Now, someone has found out that when you ask the kernel to Do Things certain way, the kernel subsequently thinks you are the Boss.

      Like, you have this stack of forms you want the computer signed. You hand them over to the computer. One of the papers is "Do whatever I say" form that would give you the Power. The computer won't read it and just signs it along with the others, then hands you the forms back.

      How's that for an explanation?

  • Important to Remember (Score:3, Interesting)

    by rudy_wayne ( 414635 ) on Sunday March 07, 2004 @11:36AM (#8491078)
    When a Windows vulnerability is patched, it is proof that closed source software is evil.

    Wne a Linux vulnerability is patched, it is proof that open source software is wonderful.

    • Re:Important to Remember (Score:5, Funny)

      by Anonymous Coward on Sunday March 07, 2004 @11:58AM (#8491222)
      TO DO:

      Log onto slashdot.
      Bash Microsoft.
      Bash the bashers of Microsoft.
      Bash the bashers of the bashers of Microsoft.
      ... ad infinitum

    • Re:Important to Remember (Score:5, Funny)

      by FattMattP ( 86246 ) on Sunday March 07, 2004 @12:09PM (#8491283) Homepage
      When a Windows vulnerability is patched, it is proof that closed source software is evil.
      You misspelled if.

    • Re:Important to Remember (Score:5, Insightful)

      by KingOfBLASH ( 620432 ) on Sunday March 07, 2004 @12:38PM (#8491399) Journal
      When a Windows vulnerability is patched, it is proof that closed source software is evil.

      Wne [sic] a Linux vulnerability is patched, it is proof that open source software is wonderful.

      You know there are -- among the many, many, many open vulnerabilities out there -- two which are particularly problematic for Windows users. (There are many more out there, but I figure I'll focus in on these two for now.

      The first one [slashdot.org] allows an attacker to mask the real address of the site you're viewing in IE. So, go and open up a spam claiming that Paypal needs you to update your credit card number, and you'll actually see PayPal.com as the URL. The second one [slashdot.org] allows an attacker to crash IE and exploit arbitrary code when a user views a picture on a web page under IE.

      As a Computer Programmer, I understand how hard it is to create 100% bug free code. Any system as complex as Windows or Linux is bound to contain some bugs and / or vulnerabilities. However, when an exploit is found in Windows (to the best of my knowledge those two exploits have yet to be patched), it takes forever to get a fix to the public.

      On the other hand, as soon as I heard of the vulnerability in the Linux Kernel, I have the following options:

      1. Patch it myself and submit the patch for everyone elses benefit
      2. Disable the use of the system call that can be used to create the vulnerability until a patch is found.
      3. Help test patches created by someone else -- possibly with much stronger C skills then mine (Hey, Linus can outprogram anyone as far as I'm concerned. There's no dishonor in being outgunned by the best)

      Now, whereas I am pretty certain Slackware will have a package available for me to update my kernel in another 48 - 72 hours, and if it's absolutely urgent for me to fix it I can either disable it or fix it myself (something Windoze won't let you do -- although the nature of the vulnerability in the kernel may make disabling it impractical. But still, at least you have the option), Microsoft has not, to the best of my knowledge, fixed these vulnerabilities, even though it's been months.

      This is why Open Source Software is so great. Technically sophisticated users hold the destiny of the software in their own hands. And I haven't even begun to get started on how great it is not to submit annoying feature requests, but to make software do what you want it to do.

  • More critical vulnerability in FreeBSD (Score:4, Interesting)

    by chrysalis ( 50680 ) on Sunday March 07, 2004 @11:41AM (#8491116) Homepage
    Another kernel vulnerability was recently found in all FreeBSD (4.X and 5.x) versions.

    The TCP/IP stack can be stopped by sending unordered TCP fragments.

    This is a serious remote vulnerability, and any FreeBSD with an open TCP port should be patched ASAP.

    Here's a link to the official advisory :

    ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisorie s/ FreeBSD-SA-04:04.tcp.asc

    Regardless of the operating system you are running, always keep everything up to date.

  • This guy investigating mremap is saving a new vulnerability for every week. He's working only to get his name printed everywhere. I cannot take this seriously. If he's a genuine security analyst, he'd fix _all_ mremap related bugs within 1 patch.

    My biggest grief, is him not releasing source code patches for genuine kernel.org kernels. If he's so good to release sploits, he's good enough to submit source code patches.

    Robert

  • Date format (Score:5, Insightful)

    by mandrews ( 139863 ) on Sunday March 07, 2004 @11:49AM (#8491167) Homepage
    disclosed on 05-01-2003

    OK time for me to tilt at a few windmills. Aside from the date being off by a year (the link quotes the date as 05-01-2004), is this supposed to be 1st of May or the 5th of January?

    In an international forum and for clarity, ISO 8601 dates [cam.ac.uk]. Therefore: 2004-01-05.

    Sorry for the rant, but I work for an international company, and have spent sizable parts of meetings trying to figure out which version of a document is "most recent", 2/3/04 or 3/2/04.

    • Or UN dates:

      03 May 2004
      31 Jan 2005
      03 Oct 2004

      Even if you do those in another language, the meaning is still much clearer than 03/05/04

      Michael

    • Can't agree more (Score:5, Insightful)

      by Craig Ringer ( 302899 ) on Sunday March 07, 2004 @12:13PM (#8491307) Homepage Journal
      ISO dates are the way to go - for the sanity of everybody concerned. They sort lexically in a sensible way, they're in a reasonable order, and they're unambiguous (YYYY- not YY-).

      This, of course, is why nobody uses them.

      *sigh*

      As the evil dictator-like sysadmin, at work all my in-house intranet tools report ISO dates. I had a few people confused at first, but now it's the accepted format at work for things like archive directories (hundreds of directories named NN-NN-NN, NN.NN.NN or NNNNNN can get rather confusing - YYYY-MM-DD is so much easier).

      Now, if only the /rest/ of the world would change over.

      While we're at it, can we have the ISO paper sizes adopted by the few holdouts, too? (I only wish...)
      • I predict the "Decamillenium bug"! Think of all those boxes that are still running 8000 years from now switching from 9999-12-31 to 10000-01-01, there goes the lexically sorted database.

        (j/k)

  • if you patched two weeks ago, you can ignore this (Score:3, Informative)

    by redmoss ( 108579 ) on Sunday March 07, 2004 @11:53AM (#8491197) Homepage
    This is partially redundant to a few of the other posts here saying that this vulnerability was already disclosed several weeks ago. However, I thought I'd add that if you already patched, check the vulnerability ID; in this case it's CAN-2004-0077. Your patch should have specifically mentioned this ID. If not, you need to patch again.

    Thank $DEITY I don't need to patch/reboot again. I was starting to get a bit annoyed at having to patch the kernel twice in two months. Scheduling reboots of machines in use by many people is no fun.

  • Patched in 2.6.3 apparently (Score:5, Informative)

    by petabyte ( 238821 ) on Sunday March 07, 2004 @11:58AM (#8491219)
    I'm fairly sure this was patched in 2.6.3. Running the test code included in the advisory on my 2.6.3 (vanilla) system shows:

    [+] kernel 2.6.3 vulnerable: NO exploitable NO

    There's also a patch to mremap listed in the 2.6.3 ChangeLog. So I don't know how "new" this bug is.

  • MS vs Linux debugging. (Score:5, Insightful)

    by innerweb ( 721995 ) on Sunday March 07, 2004 @12:03PM (#8491252)
    If this had been a bug in MS, we may might not have heard about it for months or years unless someone on the outside published it. The crackers would have still had a good chance to have known about it.

    What winds up happening is I pay MS to produce a product that I have very little input on. I buy the off the shelf solution to then develop 50% of the solution anyway. And, then it crashes, the documents are incorrect (updates might be available on their web sites), and I have no way of figuring out what the issues are without paying more $s for something I paid for already. If I tried to pull the same trick, I would loose my client.

    Linux side is someone spots the issue, makes us aware of it in most cases. People have something more important than a paycheck at stake get to work on a fix for the problem. A, or multiple, potential fix(es) is(are) put up. Sometimes a fix goes straight in with minimal review (it works, most liked it), sometimes the fix gets kicked around to hash out any potential problems (in the full light of day, normally my apps do not break when the fix is rolled out.)

    I like the public knowledge aspect of OSS. Yep, hackers have access to it also, but closed source never seemed to stop them, it just stop me from protecting myself.

    Maybe we need to look at the next step for OSS? Maybe there is a better model for building OSS? Maybe companies might start providing more donations (like cheap lic fees) to a foundation that rewards freelance OSS programmers with cash for tackling certain problems (and does not pay until the code is peer reviewed and bug checked to a reasonable extent.) Maybe that would work better... Are certain organizations not starting to do that?

    Given how much OSS has accomplished in the past decade with its relative lack of fees and "structure", imagine what might happen if more companies started using their proprietary source software budget to put bounties out on features they needed in OSS. True, not all features would they want to make public, but enough they would wat to so as to dramatically cut everyone's costs (GNU lic is important because of this). Most companies actually have very close to the same needs. But, their money goes to legal and marketing fees more than it seems to go to actual development fees with off the sheld software. What an economic waste! Check out John Nash [nobel.se] for a rather different rather OSS view of the world.

    In the end, you are left with a decision. The programmers at MS are very bright. The programmers in OSS are very bright. The real difference is the perceived safety of being able to blame MS (who you can not hold responsible yet - name one successful law suit against MS for the failure of their software to function as advertised) versus the cost effectiveness of not paying for huge legal and marketing fees (as well as other corporate overhead having very little to do with getting better or more code). I am not against programmers getting paid. I am against sloth and leeches in a corporate setting destroying the market in which programmers get paid.

    InnerWeb

    • Re:MS vs Linux debugging. (Score:4, Insightful)

      by rruvin ( 583160 ) on Sunday March 07, 2004 @12:59PM (#8491504)
      If this had been a bug in MS, we may might not have heard about it for months or years unless someone on the outside published it. And you didn't this time, either. This has been around since 2.2. How many years is that?

  • Fixed on SUSE kernels??? (Score:3, Interesting)

    by multipart ( 732754 ) on Sunday March 07, 2004 @12:05PM (#8491257)

    I can't exploit this on my SUSE kernel. All I get (after many attempts) is:

    [+] kernel 2.4.21-192-athlon vulnerable: YES exploitable YES
    MMAP #65530 0x50bfa000 - 0x50bfb000 [-] Failed

    Perhaps this hasn't gone completely unnoticed...

  • Does not compute. (Score:4, Interesting)

    by Raven42rac ( 448205 ) on Sunday March 07, 2004 @12:09PM (#8491281)
    Let me get this straight, it has nothing to do with the bug from a year ago, except that it affects the same code in the same system call? Call me unenlightened, but, that sounds pretty similar to me.

  • this vulnerability announcement is a month old (Score:5, Informative)

    by Anonymous Coward on Sunday March 07, 2004 @12:35PM (#8491387)
    this hole was found and patched by vendors a month ago. i personally submitted to slashdot at least 10 stories detailing this hole and how to patch it, and i was quite obviously ignored.

    http://www.slackware.com/changelog/stable.php?cp u= i386
    "
    Wed Feb 18 03:44:42 PST 2004
    patches/kernels/: Recompiled to fix another bounds-checking error in
    the kernel mremap() code. (this is not the same issue that was fixed
    on Jan 6) This bug could be used by a local attacker to gain root
    privileges. Sites should upgrade to a new kernel. After installing
    the new kernel, be sure to run 'lilo'.
    For more details, see:
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN- 2004-0077
    Thanks to Paul Starzetz for finding and researching this issue.
    (* Security fix *)
    "

    2.4.25 and 2.6.3 are NOT affected by this hole, and there is a patch for 2.4.24 which you can make yourself by diffing a vanilla 2.4.24 kernel with slackware 9.1's 2.4.24 kernel source package.

    CmdrTaco, before you post another "announcement" like this, do your homework. last thing we need is more security disinformation surrounding linux.

  • Are we sure? (Score:3, Interesting)

    by tomstdenis ( 446163 ) <tomstdenis AT gmail DOT com> on Sunday March 07, 2004 @12:36PM (#8491391) Homepage
    I ran the test code in the advisory on a stock 2.4.25 build and it printed out NO and NO for both questions [vulnerable and exploitable].

    Is this really a bug? [tinfoilhatmode] Is the advisory code correct? Or is this just so old that both 2.4 and 2.6 lines have it fixed already?

    Tom

  • which are vulnerable (Score:5, Informative)

    by CAIMLAS ( 41445 ) on Sunday March 07, 2004 @12:44PM (#8491424)
    Ok, so I read the write up.

    Here's the immediately pertinent part:

    Proper exploitation of this vulnerability leads to local privilege escalation giving an attacker full super-user privileges. The vulnerability may also lead to a denial-of-service attack on the available system memory.

    Tested and known to be vulnerable kernel versions are all

    So it looks like we've all got to update to the latest of respective trees. I guess the days of running a kernel for months on end are pretty much over.

  • -AC kernels not affected. (Score:3, Interesting)

    by Anonymous Coward on Sunday March 07, 2004 @12:46PM (#8491430)
    Just what the subject says.

  • Proof-of-Concept Code (Score:5, Interesting)

    by 0xB00F ( 655017 ) on Sunday March 07, 2004 @01:38PM (#8491785) Homepage Journal
    I tried the "Proof-of-Concept" code. Nice thing about it is that it tells you two things. 1) If your kernel is vulnerable 2) If your vulnerability is exploitable.

    I have one kernel that is vulnerable but not exploitable according to the Proof-of-Concept code. Saves me some time to not patch, recompile and reboot a new kernel.

    I wish future vulnerability announcements will be like this one. e.g. contain Proof-of-Concept exploit code that can tell me whether or not the kernel/software I am running is vulnerable and/or exploitable.

  • Public knowledge for over two weeks (Score:5, Interesting)

    by bigberk ( 547360 ) <bigberk@users.pc9.org> on Sunday March 07, 2004 @02:55PM (#8492177)

    The advisory [www.isec.pl] was released Feb. 18, so this has all been public knowledge for over two weeks. This USENET post [google.com] shows the vulnerability and upcoming exploit was known about, and slashdot is just plain late on this one.

    You have had two weeks to patch your systems. I know slackware's advisory [slackware.com] was sent right after the vulnerability became public knowledge.

Slashdot Top Deals

A CONS is an object which cares. -- Bernie Greenberg.

Close