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.

8 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 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.

    4. 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
  2. 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).

  3. 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.
  4. 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).