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.
There's a big difference... (Score:5, Insightful)
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.
Re:There's a big difference... (Score:4, Interesting)
Forget the firewall, get a properly implemented system.
Re:There's a big difference... (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. Haven't had a problem since.
What we really need is an article suggesting how I can speed up my downloads...
Re:There's a big difference... (Score:5, Funny)
Re:There's a big difference... (Score:5, Funny)
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.
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.
Re:There's a big difference... (Score:3, Interesting)
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
Re:There's a big difference... (Score:5, Informative)
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.
Re:There's a big difference... (Score:3, Informative)
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.
Re:There's a big difference... (Score:5, Insightful)
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..
Re:There's a big difference... (Score:5, Insightful)
Re:There's a big difference... (Score:4, Insightful)
The vast majority of Windows users behave exactly as the grandparent post states. I know this because I deal with the results every day in my shop. I'd guess that 80% of the machines I see are in due to spyware and virus problems that could have been fixed with a patch available weeks earlier. More often than not, when I get these systems up and running, the first thing that happens is "*pop* Windows has downloaded updates and is now ready to install them." So the updates were already downloaded, waiting for the user to click "Install"... but the user never did, for reasons already mentioned.
Automatic patching on XP Home would be doing end-users (and the internet!) a huge favor.
Re:There's a big difference... (Score:3, Funny)
Damned if you do...
Re:There's a big difference... (Score:3, Insightful)
Yup, and you know why? Because Microsoft tends to introduce arbitrary EULA or functionality changes in their patches. So with an autopatching system, you'd be agreeing to these changes implicitly. Whoops.
Re:There's a big difference... (Score:3, Interesting)
The reduction in spam and viruses alone would be worth the effort.
Re:There's a big difference... (Score:5, Interesting)
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.
Re:There's a big difference... (Score:5, Insightful)
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.
Re:There's a big difference... (Score:3, Insightful)
Let's be real. He has good reason to trust the company about security information, and they have good reason to present accurate information. If the software fails and he gets hacked, they company loses business at best, gets bad publicity and a nasty lawsuit at worst.
You act like people wanting easy solutions is a negative thing. Not everyone is a security expert. That's why w
Re:There's a big difference... (Score:3, Insightful)
It's not negative. It's the hubris that assumes that there _must_ be an easy solution, and whoever presents a solution and calls it "easy" must have found the right answer.
"Not everyone is a security expert."
I'm not saying they are. The point is that they assume that people who tell them what they want to hear _are_ security experts.
"The less time we spend worrying about things we don't care about, the more time we can spend on things we
Re:There's a big difference... (Score:3, Insightful)
Re:There's a big difference... (Score:3, Insightful)
What makes you think that the majority of Windows users take their computers to shops for software problems? In my experience, the only people who do that are the ones too technically incompetent to solve the problem and too socially incompetent to find a techie friend to help them.
Re:There's a big difference... (Score:3, Insightful)
This is puzzling to you? Hmm, I am more puzzled by the fact that entire COMPANIES went down when some of the worms started spreading because of unpatched systems that should have been patched MONTHS (almost a year IIRC) before.
Now, i
Re:There's a big difference... (Score:5, Insightful)
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.
I know plenty who do... (Score:5, Insightful)
In the real world, where I work, I run a Hybrid network where I'm still waiting for Windows XP Service Pack 2 to come out in a finalized form because I don't have an option to pull just the parts that I need, and SP2 RC2 is not quite ready to unleash on my network (although I have actively TESTED it). Of course, this just fixes some vulnerabilities that have existed for over a year.
Don't tell me that I, as a Windows User and Administrator, don't care. While I've ignored this kernel issue over the weekend, I get to actively compile come kernel patches and test those. I'll bet, even before my testing, that I'll be able to have a production solution by tomorrow. Even if SP2 releases this afternoon, I'll still have to test it before deployment, so the Linux solution will be in production first.
Re:There's a big difference... (Score:5, Interesting)
Sudden thought - is there much of a Windows 'community', or has it all fragmented into myriad different areas?
That's possibly one aspect in security that's often overlooked; for instance, when the recent Mac OS X vulnerabilities became known, word went around the Mac community very quickly, and people discovered new aspects of the problems, created workarounds like Paranoid Android...
There's something very similar with Linux as well - but is there a Windows equivalent of, say, Slashdot? Do Microsoft-oriented community discussion sites exist, complete with flamewars over widget styles in Microsoft Word, etc etc etc?
Or do you have to be an underdog for such a thing to exist?
Windows Community (Score:5, Interesting)
It's good reading for anybody interested, however, unlike slashdot, registration is required.
Re:There's a big difference... (Score:4, Interesting)
Re:There's a big difference... (Score:4, Insightful)
Windows users don't tend to care. They don't read Windows news sites daily, they don't subscribe to mailing lists that send out warnings as soon as a vunerability is found. They don't patch when Windows tells them to.
You know why? They don't care, they don't want to "break" anything, or they don't even know that the little icon in their taskbar is any different from their 1000 other ones in the tray.
The observation you make is correct. The group you apply it to is incorrectly targeted. Do you suppose that if all of the sudden the vast majority of these Windows users migrated to a more favored OS, they would magically read relevant OS news sites daily, subscribe to kernel mailing lists, and patch when their OS told them to? Of course not. Users are users. They're not interested in OS news or maintenance any more than they absolutely have to be (which, given the nature of modern technology, is practically nil). The fact that most computer users run Windows is largely an artifact of business dealings, not some concious decision on the part of the users.
No, the way to solve such problems for the computer users of the world is by providing better defaults, ie, automatic patching turned on out of the box. If you're part of the tinfoil hat crowd, go ahead and turn off automatic patching. If you like to patch manually and can be trusted to do it, go ahead and turn it off. But if you're part of the unwashed masses, your computer just takes care of itself.
Re:There's a big difference... (Score:3)
The only difference is that the newer Linux installs ask you how you want the firewall configured (with a pretty secure setting as the "click next" default).
While XP users are waiting for Service Pack 2.
They DO care. But are afraid... (Score:3, Interesting)
Lessons learned: (1) use Linux and keep it up-to-date with apt-get; (2) in the games partition which runs win
Re:There's a big difference... (Score:3, Funny)
Re:There's a big difference... (Score:4, Funny)
ME of course, doesn't have to be secure, it will crash itself.
XP with SP2 will start shipping within 6 weeks of final release. It's currently under Release Candidate status, meaning it should be no more than 10 years away. (That was very sarcastic, really it should be within the next 60 days unless something really bad happens with the test code).
Re:There's a big difference... (Score:5, Interesting)
Re:There's a big difference... (Score:5, Insightful)
That said, it does seem to be true that a Linux patch will appear a lot more quickly than an MS patch, and that seems to be a result of the fact that it's open source.
Re:There's a big difference... (Score:5, Informative)
Yea, the only difference is that in OSS the steps are usually covered in about a third the time.
This hit the kernel-list dated 2004-06-09 21:02:57 . It is now 2004-06-14 09:41:12 in my neck of the woods, and it is patched. The last update mentioned on the article's page is yesterday. It would appear the patch was available in no more than 4 days. It takes more than four days for a lot of vendors just to look at the goddamn report. Then they spend the next week hoping it goes away on it's own. Then they ignore the follow ups. Two months later when the submitter has had enough, they go to FULL DISCLOSURE and the vendor gets pissed off and starts attacking the person who reported it for not giving them enough time to write a patch they haven't even started on. Then they spend another month making lousy excuses for why it's not a serious issue and half assed suggestions of what you can turn off to avoid the problem. Finally, after about four months of hand wringing, press releases, and general bullshit, you might get a patch. If you're lucky, it won't require you to start the process over again by introducing a brand new vulnerability. If you're lucky.
There's a huge difference here. The Linux folks jumped up and solved the problem. They didn't sit around pissing on their hands for months and making excuses like a lot of vendors do.
Re:There's a big difference... (Score:5, Informative)
"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 [fourmilab.ch]. 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).
Re:There's a big difference... (Score:3, Funny)
Now that you really plug for it, though, wasn't there a guy in France who was on the run for publishing exploits in common Anti-Virus software? Slashdot even had a story about him. I tried googling, but "France antivirus vulnerability author" doesn't quite match the pages that I wanted.
Googling for "framed because proprietary software companies are opportunistic pigs" doesn't quite get it either.
Windows is obviously superior (Score:4, Funny)
The best way to avoid this bug (Score:5, Funny)
Re:The best way to avoid this bug (Score:3, Interesting)
Re:The best way to avoid this bug (Score:5, Insightful)
- Linux zealots moderating it down because it suggests that you buy a Mac, or
- Mac zealots moderating it down because it suggests you don't use OS X?
Gentlemen, place your bets now.Wait, (Score:5, Funny)
In case of slashdotting (Score:5, Funny)
int main(void)
{
printf("I love Windows\n");
return (0);
}
This is another reason why C should be deprecated (Score:5, Funny)
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.
Re:This is another reason why C should be deprecat (Score:4, Insightful)
Re:This is another reason why C should be deprecat (Score:3, Insightful)
Also, in light of recent events concerning the ADTI 'Samizdat' book & the author getting Tanenbaum's nationality wrong, describing Linus Torvalds as a Swede is a masterstroke.
Re:This is another reason why C should be deprecat (Score:4, Informative)
Some people are pedantic about these sorts of things. Personally my only spelling pet peeve is seeing people use 'alot'.
if you're running 2.4.25 or 2.4.26 (Score:4, Informative)
not whoring [slashdot.org].
Re:if you're running 2.4.25 or 2.4.26 (Score:3, Informative)
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.
The problem appears to be... (Score:5, Informative)
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?
I read the article too, I'm an idiot. (Score:5, Informative)
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.
IGNORE above ... new info. (Score:5, Informative)
The issue isn't that the context is gone... the issue is that the kernel is executing a non-waiting FPU instruction i.e. "fwait" on returning from the a context that flushes a user thread (i.e. return from signal handler, syscall after execve). Triggers the FPE, except the kernel isn't set up to handle FPEs properly from kernel space in this case. The problem is that the TS flag is set because it's switching tasks, so it receives a different exception, trap 7 (device_not_available). The purpose of that exception is to signal the kernel that a newly created process wants the FPU. So it attempts to set up the FPU... which ends up calling __clear_fpu again... heh... and the original exception isn't cleared yet... whoops.
What's really weird is I found this document [polimi.it], which details the potential problems of trying to use the FPU in a interrupt handler in the Linux kernel.
They brought up the potential of triggering this EXACT PROBLEM... quote "endless trap 7 activation"... only in this case they're talking about writing an interrupt routine, not returning from a signal handler. Still, they already discovered this misbehavior...
Well, you can't really call it that, though. It's was sort of by design (to make task switching faster). But the thing is you have to be ABSOLUTELY SURE that you never raise an FPE when TS is set, and you're NOT a user thread. That's what gets you burned here.
Re:Not all... (read for more info) (Score:3, Funny)
No. The proof is left as an exercise to the reader.
Who has shell access? (Score:5, Funny)
Re:Who has shell access? (Score:5, Insightful)
Re:Who has shell access? (Score:3, Insightful)
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
Re:Who has shell access? (Score:3, Insightful)
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.
Re:Who has shell access? (Score:3, Informative)
Re:Who has shell access? (Score:3, Informative)
Re:Who has shell access? (Score:3, Interesting)
Re:Who has shell access? (Score:4, Funny)
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)
Okay, I'm confused... (Score:5, Funny)
Re:Okay, I'm confused... (Score:4, Funny)
You know you have problems if... (Score:5, Funny)
If your system is a production server with 1000 on line users then do not test this code on that box.
You do NOT need shell access (Score:3, Informative)
Vulnerability in Linux, NetBSD Unaffected!!! (Score:5, Funny)
``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.
Re:Vulnerability in Linux, NetBSD Unaffected!!! (Score:5, Funny)
2.6.5 not really affected but acting odd (Score:3, Interesting)
UML? (Score:5, Interesting)
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?
Re:UML? (Score:4, Informative)
http://marc.theaimsgroup.com/?l=linux-kernel&m=
Says session just dies. Host is OK.
Re:UML? (Score:3, Interesting)
Rus
Older gcc-versions also vulnerable (Score:3, Informative)
I think we're forgetting one important thing.... (Score:5, Funny)
Know what else (Score:4, Insightful)
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.
Patch doesn't work for me, 2.4.26 (Score:5, Interesting)
What does the patch fix? (Score:5, Interesting)
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.
Re:What does the patch fix? (Score:4, Interesting)
And nobody ever said bandaids were bad, right?
Although Windows is Easier to apply patches to... (Score:5, Interesting)
FYI suse 9.1 not vulnerable (Score:5, Informative)
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)
another way to fix the problem... (Score:5, Funny)
#include
#include
#include
static void Handler(int ignore)
{
char fpubuf[108];
write(2, "*", 1);
}
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
THIS is why I hate Linux (Score:5, Funny)
How am I supposed to keep up with this stuff?
this *is* a big deal (Score:4, Interesting)
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.
Re:Open Source Community shows its Value (Score:5, Funny)
Let's just hope they're not browsing for pr0n.
Re: My Experience with the Linux (Score:5, Funny)
I think you'll need to clarify that for us slashdot folk.
Re:OS bugs are like golf... (Score:5, Insightful)
Re:OS bugs are like golf... (Score:3, Interesting)
This was made worse by the fact that many people run as admin and IIS used to run as LocalSystem on default installs.
However all software has bugs; this incident is neither proof positive or proof negative of any argument re: open source vs closed source.
Re:OS bugs are like golf... (Score:3, Interesting)
Yes, and who says these aren't present on Linux systems? Do you claim that all Linux distros have been as heavily assaulted as Windows, and kept up? I don't think so, and therefore I don't think we can say anything about the security of a Linux + libs + apps system.
Re:OS bugs are like golf... (Score:5, Funny)
Linux trolls: Windows sucks!!!
Slashdot blurb about Linux bug
Linux trolls: Windows sucks!!!
Re:Fixed quickly. (Score:4, Insightful)
The same cannot be said of many proprietary OSes...
The fact that a patch is available doesn't mean that it is a non-issue. In many cases system administrators are too busy, lasy or do not wish to interrupt services, to update their systems to fix these software vulnerabilities. The proprietary vs. non-proprietary argument is irrelevant if administrators fail to keep up-to-date with security fixes. A good example of this was the SQL Slammer worm that made it's rounds several months after a patch that fixed it's attack vector was released.
Simply put, the bigger problem is with the wet-ware than the development methodology.
Re:Fixed quickly. (Score:3, Interesting)
Also, how will I be to apply the patch and where is it? Do I have to recompile my kernel?
If this were a Windows bug, it would have been thoroughly exploited, made the news, and I would have already applied the patch by clicking "Windows Update". A bigger deal would have been made of it, but it would have only taken about a minute of my time.
I do prefer Linux, but we need to be open-minded.
Re:Fixed quickly. (Score:4, Informative)
Re:Fixed quickly. (Score:5, Informative)
Here [theaimsgroup.com] is the LKML discussion thread on the subject. It's an interesting bug, briefly summarised by Matt Mackall as follows:
So there's a bit of a massive problem with FPU exception handling, which didn't come to light before. Wheee. Fun.
Re:Fixed quickly. (Score:5, Interesting)
Re:Similar windows problem (Score:4, Interesting)
So, it's been fixed in XP SP1. Months after the flaw was reported, and with a woefully incorrect knowledge base article too.
Also, it hasn't been fixed in NT4, and it hasn't officially been fixed in 2000 either, although it seemed to go away after Win2K SP3.
Re:A good time to disable compiler access (Score:5, Insightful)
Re:A good time to disable compiler access (Score:5, Insightful)
I don't think this idea is useful.
Re:This is the best they can come up with? (Score:5, Insightful)
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).
Re:Not news. (Score:4, Informative)
help ulimit
[CORRECTION] Re:RHEL3 doesn't crash (Score:5, Informative)
My test was on a dual P4 (hyperthreading). Running a single instance of the code only locked a single cpu. I just played with it again, and running 4 instances locked the box. So RHEL3 is vulnerable, and a correct description of the problem is that the exploit locks up 1 cpu in an endless loop that cannot be stopped. For systems with multiple CPUs, you have to do this once for each cpu (twice for each physical cpu if hyperthreading) in order to lock the whole box up.