Slashdot Mirror
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.
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.
The ______ Agenda
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.
Here's a neat trick to try under Windows 2000.
:)
:) 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.
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
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.
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?
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?
Tedious Bloggy Stuff - hooray?
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".
It's good reading for anybody interested, however, unlike slashdot, registration is required.
Kinetic stupidity has a new brand leader: Allen Zadr.
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.
need a free COBOL editor for Windows?
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.
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.
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?
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.
2*3*3*3*3*11*251
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.
I spent ages trying to think of sig, but never did
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.
Engineering and the Ultimate
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.
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.