The Openwall Project provides security related kernel patches for Linux and BSD kernels.
I read about this in Hardening Linux by James Turnbull. The patch that most interested me was to prevent executable code from running in the stack. That won’t prevent all buffer overflow attacks, but it can stop some of them. I really don’t understand why this isn’t just the default nowadays – I know it can break some programs and debuggers, but it seems smart to me.
I installed this on a RedHat ES system. That system was running a 2.4.21 kernel, and had never installed kernel source, so the first step was to go get a newer kernel. I cd’d to /usr/src and did a
cd /usr/src
get ftp://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.29.tar.gz
tar zxvf linux-2.4.29.tar.gz
ln -s linux-2.4.29 linux
wget http://www.openwall.com/linux/linux-2.4.29-ow1.tar.gz
cp cp linux-2.4.29-ow1/*diff .
This patched the 2.4.29 kernel with the Openwall enhancements. I then copied the existing RedHat kernel config file so that I wouldn’t have to answer a zillion questions (most of which I probably wouldn’t have half a clue how to answer).
cd /usr/src/linux
cp /boot/config-2.4.21-27.0.2.EL /usr/src/linux/.config
make oldconfig
This did leave me with a few questions to answer for things new in the 29 kernel. I took the defaults until it got to the Openwall stuff. I then answered “y” for hardening the stack, but not for GCC trampolines because that’s apparently for older 2.0 kernels. I also said “n” to the “Destroy shared memory segments” because of warnings in the FAQ that it can break some apps and the advice of the “Hardening Linux” book. I probably don’t have anything here that would break, but I left it “n”. This ended up with these settings:
CONFIG_HARDEN_STACK=y
# CONFIG_HARDEN_STACK_SMART is not set
CONFIG_HARDEN_LINK=y
CONFIG_HARDEN_FIFO=y
CONFIG_HARDEN_PROC=y
CONFIG_HARDEN_RLIMIT_NPROC=y
I then ran the typical “make dep” etc. and after a long, long wait everything completed and I ran “make install”. That broke, complaining
grubby fatal error: unable to find a suitable template
Grubby? I had never heard of it, but “man” showed me that it is used to update /etc/lilo.conf or /etc/grub.conf. The man page mentioned templates, but didn’t explain enough to tell me what its problem might be. However, looking in /boot, I could see that everything I needed had been installed there, so I went ahead and edited /etc/grub.conf by hand. Unfortunately, I fat fingered it and ended up with this:
# NOTICE: You have a /boot partition. This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/hda2
#          initrd /initrd-version.img
#boot=/dev/hda
default=0
timeout=10
splashimage=(hd0,0)/grub/splash.xpm.gz
title Red Hat Enterprise Linux ES (2.4.29-ow1)
root (hd0,0)/grub
kernel (hd0,0)/vmlinuz-2.4.21-27.0.2.EL ro root=/dev/hda2 hdb=ide-scsi
initrd (hd0,0)/initrd-2.4.29-ow1.img
title Red Hat Enterprise Linux ES (2.4.21-4.EL)
root (hd0,0)/grub
kernel (hd0,0)/vmlinuz-2.4.29-ow1 ro root=/dev/hda2 hdb=ide-scsi
initrd (hd0,0)/initrd-2.4.21-27.0.2.EL.img
Do you see the mistake? It should have looked like this:
# NOTICE: You have a /boot partition. This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#           kernel /vmlinuz-version ro root=/dev/hda2
#          initrd /initrd-version.img
#boot=/dev/hda
default=0
timeout=10
splashimage=(hd0,0)/grub/splash.xpm.gz
title Red Hat Enterprise Linux ES (2.4.29-ow1)
root (hd0,0)/grub
kernel (hd0,0)/vmlinuz-2.4.29-ow1 ro root=/dev/hda2 hdb=ide-scsi
initrd (hd0,0)/initrd-2.4.29-ow1.img
title Red Hat Enterprise Linux ES (2.4.21-4.EL)
root (hd0,0)/grub
kernel (hd0,0)/vmlinuz-2.4.21-4.EL ro root=/dev/hda2 hdb=ide-scsi
initrd (hd0,0)/initrd-2.4.21-27.0.2.EL.img
That gave me a lovely “file not found” when I attempted to boot. Not quite realizing what I had done, I then tried to boot the second kernel, and of course that failed with the same error. Looking more closely, I spotted my problem and used the “edit” capability of grub to point it at the right kernel.
That got me back up again. Openwall includes the source code for a program to test the stack changes, so I compiled that and tried it out:
cd /usr/src/linux-2.4.29-ow1/optional
gcc -o stacktest stacktest.c
Attempting to simulate a buffer overflow exploit...
Segmentation fault
I still haven’t found out what template is needed for grubby, but I did find a patch for it: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=83512
*Originally published at APLawrence.com
A.P. Lawrence provides SCO Unix and Linux consulting services http://www.pcunix.com
