From: fulldisclosure at aphroland.org (nate)
Subject: [RHSA-2003:088-01] New kernel 2.2 packages fix  vulnerabilities

Etaoin Shrdlu said:

> Jeeze, they only stopped supporting SunOS a couple of years ago (and I
> still have the last full set of patches for 4.1.4). End of regular support
> is not the same as end of life (which happened to solaris 2.4 a while
> back). Red Hat is out of line (but then I only use Slackware, so what do I
> care).

I use debian so..

but the point I'd like to make is, unlike solaris, end users of redhat
do have the source(you can get the source to solaris, but last time I
looked it seemed pretty minimal, maybe just the kernel?? though I didn't
do a real good job of browsing the CD). You can patch it yourself. I
was quite pleased when I downloaded linux 2.2.25 to see that it was
a 6 line patch to kenrel/kmod.c. This is called by CONFIG_KMOD, a
kernel config option I have NEVER used. I've always hated the kernel
module auto loader so it's always disabled in my homebrew kenrels(which
run on all my systems). It is trivial to patch, I'm no developer and
within a couple minutes I backported the patch to my 2.2.19 trees,
then I realized I didn't need to in the first place :)

Granted some users out there may not have the skills to do such
a feat, but they can hire a consultant to do it for them, or upgrade
to a newer release of the OS(shameless plug - debian supports sparc too),
for little or no money. Contrast that to Sun/SGI/HPaq/MS where often
you do not have the source and are at the complete mercy of the vendor.
Unless they are a really big customer of the vendor and has influence
to get stuff done(one of the customers of my former employer had such
clout with HPaq, could get patches expedited to him somehow).

to be fair, debian has not announced a updated set of kernel
packages for this particular bug yet as far as I can tell.

some bugs may be harder to patch, but this one was simple, I can't
imagine why the redhat rpm wouldn't build since the patch(at least
what was in 2.2.25) was platform independant. sounds like a hard
coded setting within the SRPM itself.

just for reference, the patch(diff'd against 2.2.19):

--- kernel/kmod.c	Tue Mar 18 14:10:18 2003
+++ kenrel/kmod.c	Tue Mar 18 14:11:40 2003
@@ -155,12 +155,18 @@
 		atomic_dec(&kmod_concurrent);
 		return -ENOMEM;
 	}
+	{
+	int old=current->dumpable;
+	current->dumpable=0;	/* block ptrace */

 	pid = kernel_thread(exec_modprobe, (void*) module_name, 0);
 	if (pid < 0) {
 		printk(KERN_ERR "request_module[%s]: fork failed, errno %d\n",
module_name, -pid);
 		atomic_dec(&kmod_concurrent);
+		current->dumpable=old;
 		return pid;
+	}
+	current->dumpable=old;
 	}

 	/* Block everything but SIGKILL/SIGSTOP */

I built a kernel successfully with the above patch, but have not
booted it, I expect it to work, but as above, I don't use CONFIG_KMOD
so I don't have a need to apply the patch to my systems.

worst case? recompile the kernel and disable CONFIG_KMOD and your
done(after a reboot), assuming it's turn on in the first place(usually
is).

really, not as big of a deal as some would make it out to be, at least
for me since I was never vulnerable in the first place :)

having the source is really great sometimes.

anyone remember the fiasco with redhat and CDE a few years back? maybe
1997/8.. CDE has a buncha vulnerabilities but redhat could not fix them
since they didn't have the source, I think after that they decided to
stop using closed source stuff on their distros. That incident bit
them pretty hard, CDE was dropped pretty quickly after that. Or maybe
they had the souce but the license preventing them from distributing
a fix.

nate

Powered by blists - more mailing lists