Koozali.org: home of the SME Server

Kernel Vulnerability Fix

Roger

Kernel Vulnerability Fix
« on: January 08, 2004, 12:00:03 PM »
Anyone have suggestions to what e-smith users should do protect themselves aginst this and future vulnerabilities?

http://www.zdnet.com.au/newstech/security/story/0,2000048600,20282396,00.htm

R.

Charlie Brady

Re: Kernel Vulnerability Fix
« Reply #1 on: January 08, 2004, 04:00:52 PM »
Roger wrote:

> Anyone have suggestions to what e-smith users should do
> protect themselves aginst this and future vulnerabilities?

Unless you have modified your system, then nobody can run arbitrary commands on your server, so it already has protection against this vulnerability (and a number of others).

Charlie

Arne

Re: Kernel Vulnerability Fix
« Reply #2 on: January 08, 2004, 08:10:46 PM »
From the article:

"Both flaws allow an intruder to increase the privileges of a normal user account to the same level as the system's owner."

So, just not to install the user shell contrib might help a lot for this issue.

By the way, one other way of hacking (exept from user shell access) is to use server prosesses and the owner account of the server process to perform irregular things, leaving irregular parameters to the processes, the web server as an exsample. ("Using the url as the sword of the attack"). One should believe that in this case tis should be only a theoretical (or less than a theoretical way) but who really knows ??

Roger

Re: Kernel Vulnerability Fix
« Reply #3 on: January 08, 2004, 09:52:54 PM »
Thanks for Feedback Charlie and Arne.

Has anyone had any success installing a kernel update using vanilla kernel from kernel.org on SME server? I have had no problem re-compiling and installing from RH kernel-source but I believe RH always pre-patch their source. Anyone have any ideas?

R.

Charlie Brady

Kernel upgrade process (was Re: Kernel Vulnerability Fix)
« Reply #4 on: January 08, 2004, 11:13:40 PM »
Roger wrote:

> Has anyone had any success installing a kernel update using
> vanilla kernel from kernel.org on SME server?

Yes. It's easy. There's only a few things that you need to be wary of.

1. ppp-modules (which is required for PPTP VPN) has a dependency on (and will only work with) a particular version of the kernel. You won't have PPTP VPN capability until someone builds a ppp-modules RPM built for the kernel version you use. RPM should enforce this dependency, but as you can see in the transcript below, it doesn't.

2. The kernel rpms don't run depmod with the right command arguments, so when you upgrade the kernel RPMs, you'll see a bunch of symbol errors. Ignore them.

3. As always when you upgrade an SME server, you'll need to do "signal-event post-upgrade".

4. As always when you upgrade a kernel, you'll need to tweak lilo.conf and re-run lilo.

[root@server root]# rpm -qR ppp-modules
kernel = 2.4.20-18.7
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
[root@server root]# rpm -q --whatrequires kernel-2.4.20-18.7
no package requires kernel-2.4.20-18.7
[root@server root]# rpm -Uhv kernel-*-2.4.20-28.7.i686.rpm
Preparing...                ###########################################
[100%]
   1:kernel                 ########################################### [
50%]
   2:kernel-smp             ###########################################
[100%]
depmod: *** Unresolved symbols in
/lib/modules/2.4.20-18.7-e-smith/kernel/drivers/net/ppp_generic.o
depmod:         slhc_free_R2894cfb0
depmod:         slhc_remember_R0bc55868
depmod:         slhc_toss_Rf89e3455
depmod:         slhc_uncompress_R3bc1319e
depmod:         slhc_compress_R76135e6c
depmod:         slhc_init_R2e0e927f
[root@server root]# grep 18.7 /etc/lilo.conf
image=/boot/vmlinuz-2.4.20-18.7smp
        initrd=/boot/initrd-2.4.20-18.7smp.img
image=/boot/vmlinuz-2.4.20-18.7
        initrd=/boot/initrd-2.4.20-18.7.img
[root@server root]# perl -p -i -e 's/18.7/28.7/' /etc/lilo.conf
[root@server root]# grep 28.7 /etc/lilo.conf
[root@server root]# grep 28.7 /etc/lilo.conf
image=/boot/vmlinuz-2.4.20-28.7smp
        initrd=/boot/initrd-2.4.20-28.7smp.img
image=/boot/vmlinuz-2.4.20-28.7
        initrd=/boot/initrd-2.4.20-28.7.img
[root@server root]# /sbin/lilo -v
LILO version 21.4-4, Copyright (C) 1992-1998 Werner Almesberger
'lba32' extensions Copyright (C) 1999,2000 John Coffman

Reading boot sector from /dev/sda
Merging with /boot/boot.b
Mapping message file /boot/mitel.pcx
Boot image: /boot/vmlinuz-2.4.20-28.7smp
Mapping RAM disk /boot/initrd-2.4.20-28.7smp.img
Added Mitel-SME-smp
Boot image: /boot/vmlinuz-2.4.20-28.7
Mapping RAM disk /boot/initrd-2.4.20-28.7.img
Added Mitel-SME-up *
/boot/boot.0800 exists - no backup copy made.
Writing boot sector.
[root@server root]# /sbin/e-smith/signal-event post-upgrade
[root@server root]# /sbin/e-smith/signal-event reboot      

So, once again, here are the commands:

rpm -Uhv kernel-*-2.4.20-28.7.i686.rpm
perl -p -i -e 's/18.7/28.7/' /etc/lilo.conf
/sbin/lilo -v
/sbin/e-smith/signal-event post-upgrade
/sbin/e-smith/signal-event reboot

Enjoy

Charlie

Roger

Re: Kernel Vulnerability Fix
« Reply #5 on: January 09, 2004, 03:56:26 AM »
Thanks for excellent description of kernel update above... but :), this looks like you're still using RH kernel-source:

 "rpm -Uhv kernel-*-2.4.20-28.7.i686.rpm"

What I am most interested in, is findiing out if it's possible to use a vanilla kernel downloaded from kernel.org - For example, re-compiling source from something like  linux-2.4.24.tar.bz2

The reason for this is to solve SME kernel update problem since RH will no longer be supplying suitable updated  kernel-*.rpm

Does that make sense :)

R.

Charlie Brady

Re: Kernel Vulnerability Fix
« Reply #6 on: January 12, 2004, 04:16:53 PM »
Roger wrote:

> What I am most interested in, is findiing out if it's
> possible to use a vanilla kernel downloaded from kernel.org -

Of course it is.

> The reason for this is to solve SME kernel update problem
> since RH will no longer be supplying suitable updated
> kernel-*.rpm

They are still doing so. If they stop, someone else will take up the baton, e.g. the Fedora legacy project.

Charlie