Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Bug Operating Systems Software Linux

New Linux Kernel Crash-Exploit discovered 691

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.
This discussion has been archived. No new comments can be posted.

New Linux Kernel Crash-Exploit discovered

Comments Filter:
  • by Allen Zadr ( 767458 ) * <Allen DOT Zadr AT gmail DOT com> on Monday June 14, 2004 @09:07AM (#9418948) Journal
    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.

    • by cgenman ( 325138 ) on Monday June 14, 2004 @09:22AM (#9419061) Homepage
      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.

      Forget the firewall, get a properly implemented system.

      • by Len Budney ( 787422 ) on Monday June 14, 2004 @09:40AM (#9419226)
        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...

        • by Minwee ( 522556 ) <dcr@neverwhen.org> on Monday June 14, 2004 @10:16AM (#9419567) Homepage
          Of course you realise that by doing that you are violating several patents on "Air Gap Firewall Technology".
        • by Odin's Raven ( 145278 ) on Monday June 14, 2004 @01:17PM (#9421394)
          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.

    • by Anonymous Coward
      Here's a neat trick to try under Windows 2000.

      Open a command window (start->run->"cmd")
      Ping any host (for example a host on your lan)
      Now press F7 and enter a couple of times.

      The machine reboots :)

      This works on almost every W2K machine I've tried on, regardless of SP level. In general, local exploits like these aren't taken seriously at all on Windows. Basically, if you've got full access to the machine all bets are off, there's just so many ways to bluesceen the machine intentionally, many includin
      • by zsau ( 266209 ) <slashdot&thecartographers,net> on Monday June 14, 2004 @10:47AM (#9419880) Homepage Journal
        Didn't work for me. I just get a white screen in the middle of the command prompt with a purple border that says in purple 0: PING 192.168.0.7. Pressing Enter runs ping a couple times.

        I'm far from a Windows fanboy. I use Linux almost all the time... I just happened to have a Windows box on my network atm.
      • As for your Win2k 'sploit, I call bullcrap. Doesn't work, but a nice command history comes up, so I'll thank you for that tip.

        Oh, and saying that local exploits aren't taken seriously is both a major understatement, and a not-so-major problem. After all, you can fix all the Denial-of-Service exploits you want, but if someone has local access to the machine, they can always pull out the power cord.

        That is not easily fixed with an OS patch. Never underestimate the use of a heavy door and good locks.
  • by Athas ( 763316 ) on Monday June 14, 2004 @09:07AM (#9418951) Homepage
    It doesn't require external programs in order to crash.
  • by foidulus ( 743482 ) * on Monday June 14, 2004 @09:07AM (#9418952)
    is to buy a mac and run yellow dog on it!

    /ducks
  • Wait, (Score:5, Funny)

    by Anonymous Coward on Monday June 14, 2004 @09:08AM (#9418954)
    you want us to "read" the article and not jump headfirst into an open source vs. closed source flamewar??? :P
  • by Anonymous Coward on Monday June 14, 2004 @09:11AM (#9418975)
    #include <stdio.h>

    int main(void)
    {
    printf("I love Windows\n");
    return (0);
    }
  • by Anonymous Coward on Monday June 14, 2004 @09:11AM (#9418977)
    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.

  • by Anonymous Coward on Monday June 14, 2004 @09:16AM (#9419005)
    here's [linuxreviews.org] a direct link to the patch.

    not whoring [slashdot.org]. ;)

    • This crash most definitely works. I tested it on my freshly built 2.6.6 kernel and it locked the whole machine up; just totally freezes it. This was as a standard user.

      I suppose it is not a problem since I don't allow shell access to my machines, but I guess it wouldn't hurt to patch anyway.
  • by Ayanami Rei ( 621112 ) * <`moc.liamg' `ta' `imanayar'> on Monday June 14, 2004 @09:16AM (#9419012) Journal
    ... 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?
    • by Ayanami Rei ( 621112 ) * <`moc.liamg' `ta' `imanayar'> on Monday June 14, 2004 @09:22AM (#9419063) Journal
      The article says it affects x86 (and x86-64) only.

      So itanium, ppc, etc. are safe. But my other questions still remain.

      Note that the person who reported the bug thought they were triggering a gcc bug. As it turns out, he munged his FPU assembly instructions.
      The GCC people rightly told him to contact the lkml... it's definitely an exception handling issue.
  • by slusich ( 684826 ) <slusichNO@SPAMgmail.com> on Monday June 14, 2004 @09:20AM (#9419037)
    How many systems deployed in real world enviorments give anyone other then IT staff shell access?
    • I don't know how "real world" you'd class a University, but there are two machines I have to help out with here that students have access to for their Bioinformatics DL assignments.

      It already has a program running on it that I had to develop to detect processes using too much processor time and kill them (with warnings, messages printe dout when students log in and so on). I'll probably have to upgrade it to do the same with memory now that we have one genius who seems to be finding a way to consume 1.8Gb
      • It already has a program running on it that I had to develop to detect processes using too much processor time and kill them (with warnings, messages printe dout when students log in and so on). I'll probably have to upgrade it to do the same with memory now that we have one genius who seems to be finding a way to consume 1.8Gb of memory.

        Don't kill it, renice it. It'll still run, but it'll cede the processor to other apps when they need it. Also, ulimit can handle limiting memory.

    • by Ctrl-Z ( 28806 )
      Universities.
    • I have shell on my old dialup ISP's Sun machines, have for over a decade now. Many shared webhosting farms run on Linux on x86 and if you have CGI you basically have shell since you can run arbitrary code. Also any place that does development work under Unix probably gives their developers shell access (duh). So I would say there are a lot of places that give more than just the inner circle monks of IT shell access.
    • I work in a university environment, and maintain four shell servers for general student, staff and faculty use. It's also never a good idea to assume you're safe because a certain vulnerability is local-only, since attackers often combine a "harmless" local attack with a "harmless" unpriveledged remote attack to great effect.
    • by mattyrobinson69 ( 751521 ) on Monday June 14, 2004 @10:08AM (#9419481)
      How about these? [google.com]

      I used the search term "shell accounts", incase you couldn't think of something more relevant than "cheese" or "striped cow" to search for....
  • SCO (Score:3, Funny)

    by somethinghollow ( 530478 ) on Monday June 14, 2004 @09:20AM (#9419044) Homepage Journal
    It must be an exploit in the SCO code that is in the Linux kernel!

    ;)
  • by ThePatrioticFuck ( 640185 ) on Monday June 14, 2004 @09:22AM (#9419062)
    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...
  • by ulmanms ( 106454 ) on Monday June 14, 2004 @09:25AM (#9419084)
    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.
  • by Anonymous Coward on Monday June 14, 2004 @09:27AM (#9419103)
    This can be executed on any webhost with ftp access and a cgi-bin.
  • by RAMMS+EIN ( 578166 ) on Monday June 14, 2004 @09:29AM (#9419120) Homepage Journal
    FTFA (From The Fine Article):

    ``This doesn't affect NetBSD Stable.''

    The exploit code also doesn't work on Windows 95, nor on Menuet. I haven't tested SkyOS, because I don't have a license.
  • by mycroft_rayok ( 785750 ) on Monday June 14, 2004 @09:32AM (#9419152)
    I ran this code on "2.6.5-gentoo-r1 #4 SMP Thu May 27 19:12:27 GMT 2004 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GenuineIntel GNU/Linux" and although it didn't crash, gnome started acting all odd, and none of the terminals were responsive. They just kept printing out the prompt. Still, I could browse slashdot while the code was running, and could run some applications. Although when I went to open another terminal it opened 6.
  • UML? (Score:5, Interesting)

    by spacefrog ( 313816 ) on Monday June 14, 2004 @09:32AM (#9419154)
    Very vital question for the UML virtual server leasing cottage industry and the customers of same.

    If this were to be run on a UML session, what would happen? Would the damage be limited to that UML session, or would the host machine go down?
  • FYI... My RH7.3 with gcc 2.96 and a 2.4.20 kernel is also vulnerable.

  • by kalirion ( 728907 ) on Monday June 14, 2004 @09:36AM (#9419191)
    How do we blame Micro$oft for this?
  • Know what else (Score:4, Insightful)

    by Anonymous Coward on Monday June 14, 2004 @09:36AM (#9419194)
    As for this bug, don't start bashing Linux left and right. Linux isn't perfect, no software is. But unlike when there is a bug in windows a fix is on the way as fast as possible. In fact, there is a patch on the site right now! And for you zealots who say stuff like "No big deal, who is going to do that? No the kind of person you give shell access to." shut up. Admit that Linux is not the perfection in computing.

    You know what else makes the kernel crash? At least if you are using 2.6.5 or higher if you enable APIC/APIC-IO and you have an nforce chipset the system will lock up as soon as you do too much I/O.

  • by TDot ( 621879 ) on Monday June 14, 2004 @10:18AM (#9419581) Homepage
    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?
  • by Urban Garlic ( 447282 ) on Monday June 14, 2004 @10:29AM (#9419695)
    Question for the kernel gurus out there -- I read the article and the patch (so sue me), and it seems to me that the patch just redirects the signal-handler flow if sig==8.

    This may well protect against the example exploit, but what happens if you get a floating-point exception in the handler for some other signal?

    The provided patch does not look like a real fix, unless the deeper bug really does just involve sig==8.
  • The update may be avaliable faster than Windows, but you cannot say that it is /easier/ to apply than a Windows patch. I hate recompiling my kernel, it always takes me a number of attempts until everything works. Also my server is running Linux and is serving two houses of people with net access, I can't just take it down and mess around with it for hours while I have fun trying to get a working kernel. So regardless of when the patch was released I still need to wait until later tonight to apply the patch.
  • by sloanster ( 213766 ) * <ringfan&mainphrame,com> on Monday June 14, 2004 @11:38AM (#9420365) Journal
    Granted, this crashme program, which requires local shell access, does seem to work in some cases.

    However, it does not do so on suse linux 9.1 - it creates an unkillable process, but the system continues to run normally.
  • It's funny (Score:3, Interesting)

    by Joust ( 788072 ) on Monday June 14, 2004 @11:47AM (#9420453)
    I see comments about how it only took a few days for the open source community to respond to this bug. In a comment made by Ayanami Rei, an article is linked that is dated December 12, 2003 that details this problem. Isn't that a 6-month response time to this issue? It would appear that Linux is subject to the same patching issues as MS is, even though the reasons are a bit different.
  • by naken ( 132677 ) on Monday June 14, 2004 @11:49AM (#9420463) Homepage

    #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

  • by gosand ( 234100 ) on Monday June 14, 2004 @12:02PM (#9420582)
    This is precisely why I hate Linux so much. When I read about Windows vulnerabilities, it is something easy like "Port 1234 left wide open" or "Outlook will email everyone in the world with your penis size if you launch IE." I can comprehend those bugs. When a Linux exploit is discovered, it is all "SIGALRM this" and "__jiggawhat_ that".

    How am I supposed to keep up with this stuff?

  • this *is* a big deal (Score:4, Interesting)

    by sentientbrendan ( 316150 ) on Monday June 14, 2004 @03:27PM (#9422807)
    The *first* post I see is some bullshit lauding the superiority of the opensource development process with this as an example. RTFA. Here is some sensible info and advice.

    1. There *was no patch*. Some systems were immune, but that was completely by chance.
    2. There is a patch *now*, but the article also says people are already using the thing to crash free shell providers on day 0.
    3. The patch, at this point, requires a kernel recompile. Not everyone running linux knows how to do that. Many who do are too lazy. Don't give me some shit about how everyone running linux is so 1337 that they will be sure the have already patched their system. I know you. You aren't that 1337.
    4. Yes, this *is* a big deal. We were caught with our pants down, plain and simple. This *is* worse than any windows security issue that has come up in a long time.
    5. Please *do* compile the demo code against your system and test it. If your system crashes, please patch. Don't act like many and just ignore this, especially if you are running a server or anything that stays connected for any amount of time. It also might be a good idea to turn off your telnet and ssh daemon (yes, even ssh) until you patch.
    6. If you are *not* running linux or not running on x86, it might also be a good idea to test the demo code against your system. If you are running windows, some versions of windows *do* support possix to a limited degree. The code *might* compile. Then there is also, cygwin. This is probably a bug specific to linux x86, but it won't hurt to check.

Your good nature will bring you unbounded happiness.

Working...