Forgot your password?

Linux 2.2 DoS Attack 270

Posted by justin++
from the ooh-dats-bad dept.
A small bug in the Linux networking code has been found, and just as quickly patched. The bug affects all Linux 2.2 kernels, and can be fixed by removing "kfree_skb(skb);" from around line 455 of linux/net/ipv4/ip_options.c. Big thanks to Alan Cox on this one.

Linux 2.2 DoS Attack

Comments Filter:
  • by Anonymous Coward
    The orignal notice of it went out a little less then 5hours before Alan posted a fix to linux-kernel.. *not bad* Esp considering the alert was kind of vague (something about 'panicing under a high volume of weird (perhaps size wrong) ICMP packets')..

    Kudos to Alan and the rest of the Linux community.. Lets see a close source vendor come back with a 5hour turn around on a obscure one line logic boob bug.
  • by Anonymous Coward
    I ment Alan not Alen!!!
  • Software that's new is insecure, because it hasn't been tested. This is an axiom. People laugh at NASA and at the Space Shuttle's dated hardware and software. But NASA tests the bajeezez out of their systems because they *have* *to* *work* or poeple die. So by the time they finish fixing bugs and testing, their system looks dated. In the consumer software market, the attitude toward bugs is always, "it'll be fixed in the next release". But the next release has new features or rewritten features. The result is that the old bug may be fixed, but there are new bugs to take its place. No one ever goes back to the already released code, fixes reported bugs, makes no other changes and adds no new features and then releases the same software again. This is why Linux (and Windows 9x and NT and SunOS and...) will always be inherently unreliable. Even in the automotive world, cars with discovered problems get recalled and fixed. Why? The gov't has quality regulations (lemon laws) that force manufacturers to actually fix problems (and to fix them for FREE) in their products. Given a choice, I'm sure the auto industry would happily tell consumers with flakey cars that all will be better in next year's model and that they should upgrade/trade up. It's only because they are forced to fix the old cars that they actually do so. Software has been unregulated and "disclaiming all liability and fitness for any purpose" (from any EULA) for far too long. And if they don't shape up on their own, the gov't will step in and do it for them.
  • ipchains..tons of new drivers..i believe Video4Linux.

    im sure theres a lot more
  • I heard that RAF bombers still use core memory in the onboard navigation systems. Apparently they upgraded to pentium systems a couple of years ago, and they crashed too much. (the computers, not the planes ;) )

    I would rather have a computer on my desk that crashes occasionally, than core memory.
  • by Anonymous Coward
    A panic is a kernel crash message.. The Linux equiv of a BSOD (although many Linux panics dont cause a hard lock, and usually only kernel developers or people with bad hardware see Linux panics).
  • by Anonymous Coward
    "All" 2.2 kernels? What about those that weren't compiled with Ipv4 support?

  • by Anonymous Coward
    ran it against 2 boxes.

    (all boxes are running 2.2.9)
    Exploiter is a PII 233

    exploited 1 is a dual pentium 133Mhz and crashed after 74 and 138 "b00m"s.

    exploited 2 is a single 21164 600Mhz (DEC Alpha) and caused the "b00m" program to die after 367 packets with the following line "Unable to get host name: Connection refused".

    will continue playing and see how many will be needed to bring down the PII, but I wanna know if anyone else has noticed similar "oddities" in this exploit (ie., has anyone crashed a non-x86)?
  • by Anonymous Coward
    It goes with the purpose of moderation to weed the needless posts out from the good.

    This criteria makes no sense. The post *is* a good post. What it is repetitive aka needless in your words.

    We all know that he was trying to be helpful, and had he gotten here about 2 minutes earlier, he probably would have gained points instead of getting a -1.

    Ridiculous. He's penalized for the time it takes a slashdot page to update with the other person's post? or the time it took him to (after checking for like postings) cut, paste, and preview?

    Mind you, I agree that repetitive posts need to be cut down on. I do not see it fair, however, to negatively moderate. Don't cast it off as solely an aspect of "moderation." In most cases of moderation, there is not a peer review system. In most cases, a repetitive post would never make it through, but would also not be held against someone.

    You could simply fix the problem by adding a criteria of "useful but repetitive" such that it acts as a -1 or -2 when comments are viewed, but does not contribute to the person's "average."
  • by Anonymous Coward
    Sure, OPENBSD is a great OS. But, if you think for one second that means that your system is automagically secure, then you are in for some unpleasant surprises. Security is a continuous process. Just ask the guys at the sites you mentioned. If you think you have security just because you run OpenBSD, you are a fool.
  • ...so that you can find and report bugs.

    If all you're worried about is what Linux can do for you, it would seem you don't totally GET what Open Source is about. We all participate. If you can't code, document or test or something.

    But don't just sit back and say "2.0 works for me," because then you're just taking other peoples' work without giving anything back, and that's no way to run a community.

    If you have a machine that's not 100% mission-critical, run 2.2.x on it. And in a few months, when 2.2 settles down, run it on your mission-critical machines.

    And when 2.3.x gets past the point of exploding, start running it, and find bugs and report them and help make Linux better.

    Contribute, people, don't just take.

  • by Anonymous Coward

    That's too negative. If a particular version of open source software meets somebody's needs, who are you to say they are not benefitting the open source community unless they try a newer version and send back code and/or bug reports? One type of contribution you are completely ignoring is the satisfied user who becomes an open source advocate to potential new users.

  • by Anonymous Coward
    Quite a few people have parallel port Zip drives these days, and the driver for it under 2.2 is so much better than the driver under 2.0.x that it's not even funny. Well, at least if you have a decent parallel port, which most people do. Under 2.0.x, I was getting disk access rates so slow on my Zip drive that I would
    rather reboot into Windows just to copy files from my Zip disk. Now, the access rates are about the same as in Windows if not better.
    The frame buffer devices are also _very_ nice. Not to mention better management for modules and such.
    Really though, the clincher was the vastly improved parallel port driver. Oh, and you can print and access the Zip drive at the same time too. Very nice.
  • by Anonymous Coward
    It allows a remote user to panic a affected machine with a bogus packet.
  • by Anonymous Coward on Tuesday June 01, 1999 @02:26PM (#1871386)
    This just came to me from BUGTRAQ.
    Can someone tell me what that output means?

    Ok problem confirmed. Its not icmp however - in fact the program given
    has some bugs that cause it. If it had been a correctly written icmp tester
    it wouldnt have worked. A blessing in disguise.

    Anyway the fix seems to be this. Sorry it took so long to sort out.

    --- ../linux.vanilla/net/ipv4/ip_options.c Wed May 12 16:49:38 1999
    +++ net/ipv4/ip_options.c Tue Jun 1 22:11:46 1999
    @@ -452,7 +452,6 @@
    if (skb) {
    icmp_send(skb, ICMP_PARAMETERPROB, 0, htonl((pp_ptr-iph)- kfree_skb(skb);
    return -EINVAL;

  • by Anonymous Coward on Tuesday June 01, 1999 @01:58PM (#1871387)
    ARGH! It's a remote crash.. Most people would rather there be a remote crash then a remote exploit.. (RE in most people's minds means the attacker gets root)

    PLEASE update the post to indicate that this is a crash and not a root explot.. PLEASE!
  • No. Censorship. Evil.
  • This comment is at -1.. Another comment which was dated 1 minute earlier that contains the same information is at 5. This guy wasn't TRYING to be redundant! This post doesn't deserve to be at negative one. He posted this to try to be a nice guy.. Look what happened. He got slammed 2 points because he was down a minute, and now there's a good chance he won't be a moderator because of his negative alignment. This scares me, because I don't want to only people left with postive alignments to be moderators who hit the -1 far too liberally. Read the guidelines. Focus on promoting, not demoting!
  • oh, and if you're not behind at LEAST one firewall and you're connected to the Internet, you deserve anything you get hit with-- regardless of OS.

    So, my grandmother.. On a dialup account on a win95 box.. In a support for disability channel on IRC.. deserves to be teardroped?
  • Well.. the exploit was out there.. just not in the public. I got hit on IRC w/ nestea before the patch came out. 'Twas annoying..
  • by TechNoir (13) on Tuesday June 01, 1999 @02:08PM (#1871392) Homepage
    Bleading Edge hacker types run 2.2? Hrm. It's the stable kernel for distribution now. Anyone with RedHat 6 or whatever the latest Debian version is (Potato or something) will have this exploit. RedHat better have a fix up on their server pretty damn swiftly.
    David Coulson (TechNoir)
    themes.org Senior Developer
  • by Gleef (86)
    LinuxHQ is having DNS problems (the owner of the name took it back). The maintainer (Jim Pick) had just enough warning to preemptively get another DNS name (kernelnotes.org). Therefore, the LinuxHQ site is currently up and happily running at http://kernelnotes.org [kernelnotes.org]. If you want more info, check out the announcement [kernelnotes.org].
  • The same number of security holes are present in proprietary OS's. They're not easy to find without the source code, however. The holes that are found, if they're announced by the vendor (or kept secret), typically do not come with solutions.

  • I had similar problems with 2 IOMEGA Jaz Drives. The fact is that a good number of IOMEGA Jaz/Zip drives are defective. One of the better known problems is discussed at this page [grc.com].

    IOMEGA makes garbage hardware. It's a cryin' shame that they have established such a monopoly in the removable media industry.
  • Then I could wait 5 months for a 40 meg download that fixes 10,000 bugs yet introduces 15,000 more. Boy I wish Linux were more like NT. Really, I do.

    - A.P.


  • banner -w80 'Linux Still Sucks!'

    A classic newbie prank is to pipe the output of banner to write to disply obnoxious stuff on someone else's screen. (It's almost as classic as using xloadimage to change someone's root window to a hardcore porn pic). This guy obviously hasn't gotten over it, though honestly I laughed my ass off when I saw it.
  • Can anyone confirm whether or not this affects 2.3.x kernels? The line in question is present in 2.3.4 (which came out today, though you'd never know it, 'cause Rob appears to have knuckled under to the 31337 weenies and quit announcing dev releases), so my guess would be yes...
  • Yeah, I know. It's been down for extended periods several times since the name change, though. And even when it is up, the linux-kernel archive is still stuck at the third week of May.
  • The new 2.2.10pre2 patch includes this fix.
  • by John Campbell (559) on Tuesday June 01, 1999 @06:12PM (#1871402) Homepage
    I found Slashdot's kernel announcements to be a useful place to hold discussions about the new kernels that didn't belong on linux-kernel. With LinuxHQ's list archive no longer current (and LinuxHQ itself down seemingly as often as not) that resource would be even more valuable, but, no, we don't have it any more because a few morons who don't think that newbies should know about all that scary development stuff made a big stink here and on the kernel list.

    And who are you to be saying who "needs" to be running 2.3? I probably don't _need_ to be running it - I'm not working on USB or any of the other stuff that's new in 2.3 - but I am anyway. I figure that if it nukes my box, no problem... I'm not doing it on a main server for exactly that reason. And I might run across a problem with it that others wouldn't because of my particular hardware setup... I doubt there are many people doing kernel dev on a 386. And then I can either track down the problem myself (though I can seldom do it fast enough to keep up with the fixes that everyone else is sending in) or submit a bug report to linux-kernel so someone else can track it down. That's how free source works.
  • But what good are all those if you have to reboot every two days every time a new bug is found?
  • Posted by FascDot Killed My Previous Use:

    ...from someone who doesn't know how to use a dictionary.

  • Posted by Rafl:

    So, when it says 'to comment', means that section of the code is 'not to be executed'!

    All the time I thought that the author is requesting critiques or comments on the quality of his code. ...I'm learning.
  • Posted by The Masked Miscreant >:):

    There's more 'casual users' here at /. than you realize. Me, for example. There's probably a fair number of 'suits' who browse through here too.

    Mind you, I have no intention of remaining a 'casual user' forever, I just don't have the experience with the OS yet to be comfortable enough with it to be of any real help on any of the projects I'm potentially interested in.

  • 2.0? Most Linux users would be served well by 1.2.13. For that matter, most people don't need computers at all so who cares what version of Linux they want to run? In any case, 2.2 is just fine. If you think it's so unstable, you have two choices:

    1. Find and fix these innumerable horrible bugs [that nobody else seems to know anything about], or
    2. Fork the codebase; start with 2.0.36 (since it's obviously the best version ever [except that it sucks]) and make your own 2.2.
  • Did removing this kfree_skb call cause a memory leak? Or was the memory free always unnecessary?

    If I ever fix a bug in my code by removing a call to free() I tend to get very suspicious ... I'm not suggesting that the people in the know kernel-wise haven't considered this, I just find it odd that a free can be so readily removed without requiring new code elsewhere to make sure that the memory really does get freed at the right time.
  • Probably a little of (b) and some of (c) as well. Someone had too much time on their hands, methinks. Apparently the original poster didn't get the concept of quick turnaround on fixes - there may be bugs, but when they're found, they can be fixed, and that fix propagated quickly. Some people never learn...
  • Hmmm... how does that make it not an exploit? It seems like it could be used as a denial of service exploit at the very least. Also, crashing can be used to run specific code in some cases where there is a buffer overflow (although I don't know if that's applicable here). There was a bug found in IE awhile back that caused it to crash (I think it's archived at the l0pht somewhere) and the person who found the bug (dildog) was resourceful enough to turn it into a serious exploit by controlling the buffer overflow.
  • >the kernel "panics" and tries to kill everything
    >nicely and sync up but it well, never works right

    But of course. If it was in a condition to do it right, it probably wouldn't have to panic :) So it tries to do what it can, and hopes that that's better than nothing.

  • I was amazed when I discovered how long a 2.2 was out before the first 2.3 became public. Shouldn't there be roughly 2-2 2.3 releases for each 2.2 release? Shouldn't there have been at least several 2.3 releases out before 2.2.0 went out?

    Nope, the 2.1 series led up to 2.2, while 2.3 leads to 2.4. There were "at least several" (ahem!) releases in the 2.1 series.



  • I was more impressed when the patch for the nestea exploit was released 2 days BEFORE the code to exploit it was released. It would be nice of everyone who found a bug wrote a patch for it instead of an exploit.
  • I 'bother' to use 2.2.x myself because it's helluva lot faster than 2.0.x in my experience. If you run a P/100 with 32MB RAM, you know what I mean.
  • The past of Red Hat's security measures? eh? They always seemed fairly fast to me. They beat any commercial vendors, and as far as I can see any Linux distributions except debian.
  • Yeah it is. It's a chink in the programming that can be exploited for the purposes of Evil.

    Maybe, but you don't fly your desk. I think.
  • So if Slashdot is your source for kernel development news, you've got some problems of your own to deal with.
  • Is that a mix between a segfault and a SIGSEGV? Don'
  • ...from someone who can't think.

  • *sigh* I was hoping the smiley in the topic would explain, but my post was an attempt (and apparently an unsuccessful one) at being humourous. The previous poster used the word "sigfault". I believe the quote was "a kernel panic is similar to a sigfault in userland" (I'm too lazy to go and look at the real quote). It would seem that he was thinking of both "segfault" and "SIGSEGV" in his mind, and then proceeded to mix them up. It is this mixing up which I thought created a humourous situation. Haha you see because there is in fact no such thing as a "sigfault". And haha, well...the joke is dead now so I guess it doesn't really matter.
  • Most C compilers these days accept C++ style comments (since they're usually C++ compilers "slumming" for the purpose of compiling this bit of C code -- but I've even seen ANSI C compilers that don't do C++ but nevertheless suppose that comment style). Some people say you shouldn't use that commment style, even when it works, because it's not portable. Theoretically, there are still C compilers out there that barf on it. (Does anyone know of any, though?)

    On the other hand, if it takes you more than 3 minutes to write and compile a C filter program to remove C++ comments from a file, you're not a Real Programmer(TM). But seriously, it's a trivial task -- so trivial that I don't see this as a good reason for not using C++ style comments these days in straight C code...


  • Well, you can make problems like this public, which means that, as you say, there's a 50/50 chance the cracker will hear about it before the sysadmin. This is assuming the system is currently under attack -- otherwise the sysadmin simply fixes the problem before the pissed-off employee becomes a cracker, and there's a zero chance of exploit.

    Or you can keep the problem private, meaning the cracker will almost certainly hear about it before the sysadmin, assuming he's out looking for vulnerabilities while the sysadmin is busy doing his job, which unfortunately encompasses much more than spending 24/7 looking for vulnerabilities no one will tell him about.

    The suits may think twice, but what are they going to do, stop using computers? That's the only way to prevent this sort of thing.

    Since you say "that isn't good enough", what should be done instead? What would be "good enough"? For software to never have bugs in the first place? That would be great! Oh, and have I have a little of what you're smoking? It sounds positively blissful...

    Stick our heads in the sand and ignore the problem? That doesn't strike me as useful.

    Switch to an OS where solutions don't appear within hours? That doesn't sound very smart.

    Please, pray tell, since the situation here isn't "good enough", what is?


  • It's about 4hrs slower than the teardrop fix, if your calculations are correct. Still, much faster than any patch or bugfix MS has ever made.
  • *All* OS'es suffer from DoS exploitable bad code.
    I had to patch the /sys dir on my FreeBSD box for
    some exploit too.
  • Well, there goes 70+ days of uptime. Damn.

    Good thing with a full packet log though, running on a box with a non-affected kernel :)

    Isn't this the first serious remote crash bug in the 2.2.x series ? There have been other bugs allright, and there still is, but I believe this is the first remote one.

    That is not bad, if one thinks about the _huge_ changes that went into the 2.2 series from the 2.0 series. I'm pretty amazed we haven't seen a few more of these already... They may be coming though.

    I would have expected a bug like this to appear sooner. And I would have expected more of these bugs. Well, either the developers are blessed with luck, or they are really skilled. We'll see which, in the next few months I guess. Luck don't last.

    Good work guys ! Also on the fix btw. :)
  • ipchains and ipmasqadm. two *awesome* tools that I don't know how I lived so long without.
  • what OS he/she(it? are trolls gendered?) used to make that banner? ;-)

  • knfs.


    2.2 also kicks ass on multiproc machines. but you
    already knew that ...

    traffic shaping too...

  • The people I knew in school that would do that kinda crap would just pipe over a 10 mb gziped binary to your ptty. If you didn't know better it was enough to piss ya off and wreck your whole day.

    or your whole term session anyway ...

  • Regarding traffic shaping, did you know there is traffic shaping in 2.0.36?

    No I didn't. Cool.

    As far as knfsd goes, yes I did measure it. It was between 20 and 30 percent faster for my app. it was a custom application that abused nfs for commo. (yes i do know how to use sockets! ugly app. don't ask :-) YMMV. I had been using BSD only because I found the Linux user space nfs to be to damn slow. knfs made a huge difference for me. Your right about the ext2fs stuff, it has been a pain for me too ... Unfort i'm not a filesystem guru.

    Regarding SMP, most PCs are not SMP, and, I guess, most Linux users' PCs are not SMP.

    I think you would be suprised. I'm finding more and more people I talk to run SMP boxes. But then most of them are eengineering/scientific types so I may have a tainted sample base. or something.


  • by Bwah (3970) <RndmNmbr@gm[ ].com ['ail' in gap]> on Tuesday June 01, 1999 @03:16PM (#1871433)
    I would love to agree with you, but can't.

    It would be damn near impossible to run a full qual. test on a modern OS. The complexity level is just to high and there are really no requirements to test anyway. The government will not (I hope) step in here. There is no reason for them to do so.

    Think of it this way: it takes WEEKS of 24 hour computing to run a FQT on an aircraft digital flight control system. WEEKS. and this is a system with super super rigid, well defined, realtime requirements. There is no code in the system that is not used.

    Now consider the Linux kernel. How many system calls are in there that joe average user never touches? How many combinations of things could be going on at one time? For all intents and purposes we are dealing with an infinite combination regression test situation here. or something. :-) You can't ever really test this kind of general purpose system.

    With the complexity in modern realtime and avionics systems, we are pushing the limits of software test. Formal qual testing of general purpose software is a lost cause.

    i'll stop rambling on now ...


  • From the archives at www.geek-girl.com [geek-girl.com]

    Linux kernel 2.2.x vulnerability/exploit

    Piotr Wilkin (pwl@WOTAN.2SLO.WAW.PL)
    Tue, 1 Jun 1999 17:43:17 +0200

    Next message: Salvatore Sanfilippo -antirez-: "whois_raw.cgi problem"
    Previous message: aleph1@UNDERGROUND.ORG: "New Allaire Security Bulletin (ASB99-09)"

    I'm sorry if this has been noticed before, but since I did't find anything
    in the archives, I post it here.
    There seems to be a bug in kernels 2.2.x (tested on 2.2.7 and 2.2.9), that
    causes them to panic when they are sent a large number of specific ICMP
    packages. I think the problem comes from the combination of the mangled
    header length (shorter or longer ihl's don't cause hangup) and the random
    ICMP packets (random type/subtype and source address) this program sends.
    Windows 9x and FreeBSD 3.0 seem to be unaffected.

    I think the most interesting thing is the date, though... I'm sure I'm making a timezone mistake here, but isn't that 8 hours ago? Is that faster or slower than the Linux teardrop fix?

    It's annoying to find out about a new DOS attack, but the resolution is all that you could hope for.

    It's a little less annoying that there don't seem to be any outstanding instant-crash attacks against Win98 to laugh about - they finally fixed the series of attacks that crashed 95 for 8 months straight, and I haven't seen anything since. Did Microsoft finally get their IP stack right?
  • echo 'main() {exit(0);} // useless program' |
    sed 's#//\(.*\)$#/*\1 */#'
  • Hyuck! Jus' kidding!

  • When "found" = "fixed" I think it's well worth it.
  • But then most of them are eengineering/scientific types so I may have a tainted sample base. or something. I'd say such users are a significant minority of Linux users nowadays. The fact that Linux can continue to grow in sophistication and reliability AND be useful to lesser-skilled users is evidence of a high degree of Engineering Quality. A rare thing nowadays!
  • Oracle, eh? Hmph. Ever used it?

    I'll go with the College kids. Hell, I'll go with the drunk college kids!
  • A remote xpilot? oh... nevermind...
  • Yes. But the point is that you don't want random people on the internet at large to be able to send bogus packets to your machine that cause it to panic.

    Obviously there's no way to protect the machine against someone with superuser privileges from panicing it. But it is important to prevent unauthorized people from getting superuser privileges.

  • A segfault is something that happens to a process, usually due to a bug in user-space code. That process may have to be aborted, but the integrity of the kernel is not compromised.

    A panic occurs when the kernel detects a condition that should never happen, and from which no good recovery is possible. It should not be possible to cause a panic from user-space code (except perhaps by root processes doing naughty things like scribbling on /dev/kmem).

  • Actually, patching running operating systems used to be standard practice in the time-sharing days. Of course, you have to be very careful.

    With Linux, just figure out where the offending instructions are by groveling through the compiler and linker output, and write to the relevant locations in /dev/kmem. For this particular bug, you probably only have to NOP out a few instructions.

    Personally, I'm just as happy to reboot. It's not like it takes very long, and it's easier and safer. But if I were running a mission-critical 24x7 system, perhaps I'd think about it some more.

  • Kernels should remain in development until they reach true stability.
    Sure, that's a nice idea. Motherhood, apple pie, etc. But you obviously aren't a real-world software developer.

    What you propose won't work for several reasons:

    1. Linus can't hold the development tree in a code freeze for the time it would take for the build to stabilize to the degree that you're asking for ("true stability"). If he tried, the various developers would fork off their own Linux kernels, and we'd have a big problem, worse than the egcs vs. gcc problem (which fortunately has been resolved).
    2. If the kernel didn't get released to the "stable" branch at some point, it would never reach your desired level of "true stability", because not enough people would beat on it and find the bugs. Linus' policies are geared toward making sure that it seems pretty good before it is released to the stable branch, and then to shake out the remaining bugs.

    Can you cite a single example of a software project of comparable complexity to the Linux 2.2 kernel which had fewer bugs at initial release? I didn't think so.

  • I doubt the moderator thought that he was trying to be redundant, but it still is redundant, regardless of the fact that it wasn't his intention. It goes with the purpose of moderation to weed the needless posts out from the good. We all know that he was trying to be helpful, and had he gotten here about 2 minutes earlier, he probably would have gained points instead of getting a -1.

    Also, having a single post at -1 won't throw off his alignment a great deal as long as he consistently gets his other posts bumped up a notch or two. Don't forget, too, that there are a few other items to be considered as to whether he gets access or not.

    -mike kania
  • What's funny is that this post is marked as flamebait, but it has a score of 2. :)

    Such irony!

  • There's a garbage collector for Unix-domain sockets already.
  • Samba uses TCP/IP

  • Rather than let this dipshit have the last word, thought I'd mention that my box running 2.2.8 with ipchains firewalling and a rule banning incoming ICMP is NOT, i repeat ***NOT*** vulnerable to this exploit... just FYI. oh, and if you're not behind at LEAST one firewall and you're connected to the Internet, you deserve anything you get hit with-- regardless of OS.


  • Linux is buggy! Yay Microsoft!

    Sorry, just had a moment of strangeness.
  • I wouldn't call it "knuckl[ing] under to the 31337 weenies", really. If you need to be running a 2.3.x kernel, you're following development elsewhere. End of story. I think it was fine to announce the beginning of the 2.3's, but if you need more than that, use the LinuxHQ slashbox or LinuxHQ (kernelnotes.org), or follow linux-kernel.

    Ian Peters
  • Look at the version number on your 2.0.36 kernel. Thirty-six. This means that it went through over *THIRTY* major revisions before it became "stable" ... and that's if you *don't* count the AC patches.

    It's more stable solely because it's older. Wait until 2.2 gets a bit more mature, and it'll be just as stable (if not moreso) than 2.0 is, and will beat it senseless in the performance department as well.
  • by Bilbo (7015) on Tuesday June 01, 1999 @06:58PM (#1871453) Homepage
    Uh... before you apply this patch, notice that the "less-than" in the icmp line should actually be doubled (i.e., a left shift opperation)! The second less-than symbol got swallowed somewhere in the HTML conversion.
  • This is known for long. Win95 (and 98?) count time as milliseconds since boot in a 32-bit variable. If you do some calculations you will find out that it will wrap around after 49.71 days.

    For a comparison: Linux counts hundredths of seconds (except on the Alpha, where it too is ms but 64-bit) and will therefore last ten times longer until wrap around. However, kernel code is expected to survive a wrap and debugging is done in this area (like setting the timer variable to a few minutes before wrap at boot time and see where problems arise - 2.2 should have eliminated most of them).

  • Speed!!!

    2.2 also kicks ass on multiproc machines. but you
    already knew that ...

    I have to say that i do own a SMP system and using a 2.2.7 kernel was personnaly a real pain even though it took 2 weeks to discover it.

    With the same configuration but with 2.0.36 (UP) kernel, the system was more responsive. I have now switched to the devel series (2.3) and it works quite nicely.

    greetings, seb.
  • See the following:

    http://www.ntsecurity.net/scripts/loader.asp?iD= /security/casesensitive.htm

    In short, every version of NT has a security exploit that allows any user to get root access. That's a far greater security risk than this DoS attack, which can simply crash your system.

    It has been known for over ten weeks. And AFAIK, Microsoft hasn't released a fix (at least I can't find one on microsoft.com). It is possible that NT 4.0 Service Pack 5, released six weeks after the hole was found, fixes it -- for NT 4.0 users and NT users willing to pay to upgrade to 4.0 only.

    Now, which is a bigger deal -- a DoS attack fixed eight hours after publication, or a root exploit unfixed for at least six weeks after publication?

  • "Do you think the suits want to 'become part of the linux community'? "

    One certainly hopes. It would be a good step in accord with linux becoming part of the business community.

    "Do you think the casual user actually wants to be involved in tracking down and reporting bugs?"

    No, I realize the casual user wants to be blissfully unaware of anything at all. This applies to lots more than computers. (Driving, for instancce -- I don't think the casual driver wants to be involved in avoiding traffic accidents except those involving him.)

    "No average user is interested in 'running a community'."

    Wait just a minute. The average Linux user is,
    or ought to be. Or else somebody missed something fundamental about what linux is somewhere along the way.

    "They don't want to contribute to making an operating system, and that's why they
    continue to pay for software instead of going open-source."

    What's wrong with that? Is this how you characterize the average *linux* user? You're using windows users to illustrate the beliefs and
    behaviors of linux users. I have a real problem with that.
  • I was trying to figure out why this kfree()
    broke things, and trying to figure out where
    it was freed elsewhere.
    Could the root of the problem really be the
    program logic, which is implemented using a nonzero number of goto's?
    I realize that goto is only being used for throwing exceptions, but still... if you're
    using goto's in code with malloc's, you're asking for trouble.
    But then, I'm no kernel hacker...
  • "a rule banning
    incoming ICMP"

    has your box breaking MTU path discovery, making
    you a bad netizen.

  • 2.2 is a stable kernel, not a "bleeding edge" kernel. They're very stable...

    In fact, I consider them more stable than 2.0 systems in many way... better, more dependable memory management is just the first of these improvements.
  • You can't put free's in like candy. Taking out free's is generally bad but adding extra ones is much worse...
  • By Microsoft's own admission (before the article was taken off their Knowledge Base), Windows NT and 9x can only be on for 49.7 days - max - before it will crash... of course, most people can't make NT or 9x run for more than a few days

    This is not quite accurate. The actual bug was in Windows 95 (still in 98? Don't know). They discovered that the uptime counter rolled over after approximately the number of days you mentioned, and crashed the box. This was discovered, if I remember correctly, earlier this year (it seems that in 3 and 1/2 years NO ONE had ever successfully kept a Win95 box up for that long!).

    NT, however, does not suffer from this particular bug. I have a client who managed to keep his NT box up for at least 78 days -- mostly because the machine was so little used (he's an exec, not a geek). After 78 or so days, he had next to no free RAM left for anything. The leaks in the OS itself had plugged the system horribly. Nevertheless, this man did successfully run it for 78+ days.

  • For Windows 95: "Guess I'll have to shell out $90 for the 98 upgrade now."

    For Windows 98: "I sure hope that there aren't any more delays on that service release! It's been a year already! I hope this bug's covered in it or I'll have to wait another 6 to 8 months!"

    For Windows NT: "Lessee, I can apply this 'unsupported' hotfix that Microsoft released...or I can wait for Service Pack 6 due in 3-6 months..."

    Meanwhile, for Linux, it's this: "5 hours for a patch? What TOOK so long???"

  • As others mentioned before: filtering ICMP wholesale is not the right thing to do. It breaks path MTU, redirects (if you need them), and attempts to connect to machines that are down take forever to time out, because you don't get any 'host unreachable' messages.

    Firewalls are not the answer to these problems either. These bugs need to be fixed, dumb protocols need to be fixed or discarded, in stead of patching things up with kludges and afterthoughts like IPSEC, firewalls and the like.

    It would be nice if people would start designing protocols with security in mind, in stead of trying to add it on afterward.
    Sorry about the rant.

  • by Parity (12797) on Tuesday June 01, 1999 @04:02PM (#1871482)
    Nobody's answered the coward's question yet?
    The answer is, basically, that the output is patch-style diff output. It says that comparing ip_options.c in the linux.vanilla hierarchy to the ip_options.c in the current hierarchy, you can make vanilla like current by removing the line that says 'kfree_skb(skb);' ; in other words, that's the technical version of what was mentioned on the main article.
    I have a memory like a sieve, so I won't attempt to tell you how, but you can take those lines and pipe them through diff and patch your kernel that way. I think it may be as simple as being root and doing 'patch filename', but if I were you I'd check the manpages (for diff, and patch) before trying anything. For a one-liner it's probably just as easy to cut it by hand.

  • Even so, this does show that the current system may be out of wack.

    Perhaps only some forms of comment-downgrading should count against one's user total? Like Flamebait or Troll, while Offtopic and Redundant will only affect the single comment and not your alignment?

    Designing a proper comment rating system is hard work, to be sure. I wonder if Godel's theorem that no set of logical axioms can be both consistent and complete extends to ANY SYSTEM, be it a comment-rating system, or an OS? Heh...reminds me of the other comment here suggesting a formal proof of an OS...microkernel territory there...probably the extending of Godel to any system is one of those truisms that can't be proven...totally meta...

  • [snipped from bugtraq, dated jun 1]

    From: Piotr Wilkin
    Subject: Linux kernel 2.2.x vulnerability/exploit

    in the archives, I post it here.
    Windows 9x and FreeBSD 3.0 seem to be unaffected.

    [exploit code snipped, check www.geek-girl.com for it in the archive if you really need to know]
  • The double-slash was originally intended to work with C++ only, not C. People liked the idea so they started using it in C as well. Then it finally became a standard.

    However, not all compilers have not caught up. I don't know of specific examples, but some Unix variants still do not understand it. Therefore you should not use it if you intend to make your source code widely available. And if you think your source code will never, ever be widely available or maintained by someone else, think again.

    Incidentally, in C and C++ another way to comment out source code is like this:

    main() {
    char *s = "Hello world!";
    #if 0
    s = "World, hello!";

    Since "0" is always false, s = "World, hello!" will not be compiled.

    That way the commenting can be nested and you can be sure compilers will recognize it. A drawback is that colorized editors will not recognize it as a comment. Another drawback is that there is no equivalent in Java and you have to fall back to regular comments.
  • what do you mean when a computer "panics"?
  • by maw (25860) on Tuesday June 01, 1999 @02:39PM (#1871509) Journal
    Justin said linux/net/ipv4/ip_options.c . This seems obvious to people who've been using Unix for years, but to newbies it apparently doesn't; I'll explain.

    linux/ means the directory where the Linux kernel sources live. Typically, when one refers to linux/ one means /usr/src/linux/ although this isn't a given. net/ means the dibdirectory called net/ ; ipv4/ means the subdirectory of net/ called ipv4/ ; ip_options.c is the file you want to edit. You want to open this file with your favorite text editor, preferably one that displays line numbers somewhere. (You can toggle whether emacs displays your current line number with M-x line-number-mode.) To comment out C code, you can use /* ... */ . Comments like these can't be nested. It's pretty easy to comment out large sections of code like this. (You'll fairly often see people using // for comments in C code, but it's a bad idea, and you shouldn't do it. Don't Be That Guy (tm)!)


  • The instructions (as they appear on a previous reply to your post) are quite straightforward. Now, about recompiling - It shouldn't take that long. If you just compiled 2.2.9, then this patch will only take a few seconds to get compiled, make will automatically notice this is the only file with a modification time newer than the object (compiled) code.
  • by Vladinator (29743) on Tuesday June 01, 1999 @02:18PM (#1871520) Homepage Journal
    How about in future articles, you post a link to the patch as well? This would be very helpful to newbies like myself who don't quite know where to find everything yet...

    And I JUST compiled 2.2.9 today!!! Arrgh!
  • The bug was that they had already freed that memory else where.
