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

if you're running 2.4.25 or 2.4.26

[Anonymous Coward]

here's a direct link to the patch.

not whoring. ;)

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?

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.

You do NOT need shell access

[Anonymous Coward]

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

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.

Older gcc-versions also vulnerable

[kghougaard]

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

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

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

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

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.

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

[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