Chapter 8 Installations

We have seen so far the principles involved to attack a system using buffer overflows, as well as the principles which may be used to counter such attacks.

Now we are going to see how to install such protections; the machine we use for tests runs Linux, Debian Potato.

8.1   Installing Libsafe

All we need to install Libsafe may be found there:

ttp://www.research.avayalabs.com/project/libsafe/

Several possibilities are offered to install Libsafe, depending on your Linux distribution. Packages exist for RedHat, Mandrake, Debian, and an installation guide has been written for Suse.

We choose to install the latest version (libsafe-2.0.9), which implies to download the tarball and compile the sources.

glaume@sothis:~/tmp$ tar xzf libsafe-2.0-9.tgz glaume@sothis:~/tmp$ cd libsafe-2.0-9 glaume@sothis:~/tmp/libsafe-2.0-9$ ls

ChangeLog   doc exploits   Makefile src

COPYING       EMAIL_NOTIFICATION   INSTALL     README tools glaume@sothis:~/tmp/libsafe-2.0-9$

The interesting directories are:

• src: library sources

• doc: man and libsafe whitepaper

• exploits: a set of exploits libsafe detects

Note that we do not find the usual ./configure file! The INSTALL file only recommends the make; make install commands. We have a closer look at the src/Makefile and EMAIL-NOTIFICATION contents: libsafe offers an email notification system to advertise the machine administrator when a buffer overflow attempt is detected, which is quite annoying when you intensively test libsafe possibilities, so I would say it is a good idea to comment its activation in the Makefile, at least in the beginning:

DEBUGGING OPTIONS #

# Use

# -DDEBUG_TURN_OFF_SYSLOG to temporarily turn off logging violations to

# syslog.    ONLY USE THIS FOR DEBUGGING!

# -DDUMP_STACK to see a printout of the stack contents when a violation

# is detected (dumps to LIBSAFE_DUMP_STACK_FILE or stderr if that

# file cannot be created)

# -DDUMP_CORE to create a core dump when terminating the program.

# -DNOTIFY_WITH_EMAIL if you wish to be notified via email of security

# violations that are caught with libsafe. DEBUG_FLAGS        = -DDEBUG_TURN_OFF_SYSLOG \

-DDUMP_STACK \

-DLIBSAFE_DUMP_STACK_FILE=\"/tmp/libsafe_stack_dump\" \

-DDUMP_CORE \

# -DNOTIFY_WITH_EMAIL

Then you can compile and install the library: type make in the top directory, then su root, type make install, and it is done, you should have a /lib/libsafe.so.2.0.9 file on your system.

We have not encountered any trouble during the compilation or installation phase, and no special lib/package is necessary here.

8.2   Patching the Linux Kernel with Grsecurity

Here is explained how we have processed to use Grsecurity functionalities, by patching a 2.4.17 Linux Kernel.

The patch we use (grsecurity-1.9.3a-2.4.17.patch) may be found here: http://www.grsecurity.net/download.htm

First we should get the 2.4.17 Kernel sources (from kernel.org for instance). Let us consider we have these sources in our /usr/src/linux directory. We copy the patch in this directory, and patch the Kernel:

sothis:/usr/src/linux# cp /tmp/grsecurity-1.9.3a-2.4.17.patch . sothis:/usr/src/linux# ls

COPYING Makefile arch include lib

CREDITS README drivers init mm

Documentation  REPORTING-BUGS  fs ipc net

MAINTAINERS       Rules.make grsecurity-1.9.3a-2.4.17.patch   kernel scripts

sothis:/usr/src/linux# patch -p1 < grsecurity-1.9.3a-2.4.17.patch

Then we can see a succession of 'patching file foobar' lines, each one telling us a new file has been patched.

Once it is over, we are ready to configure our Kernel: we type make menuconfig. You may see what it looks like in appendix page A.1.

The last menu entry (Grsecurity) has been added by the patch; let us enter this section and activate the Grsecurity field: this makes a list of new sub-menus appear.

We select the first one (Buffer Overflow Protection), which lets us see five new items:

• Openwall non-executable stack (NEW)

• Randomize mmap() base (NEW)

• Read-only kernel memory (NEW)

• Fixed mmap restrictions (NEW)

Now we can activate one of these functionalities (we are mainly interested in the first three, so for instance let us choose the first one). Details about these items are available in their help sections.

Once our Kernel configuration is over, before compiling, we may wish to give an appropriate name to our brand new Kernel. If we have selected the OpenWall option, we may do this:

sothis:/usr/src/linux# vim Makefile VERSION = 2 PATCHLEVEL = 4 SUBLEVEL =17

EXTRAVERSION = -grsec-1.9.3a-ow

We are definitely ready, let us compile: sothis:/usr/src/linux# make dep clean bzImage modules modules_install install

At this stage, we have got a /boot/vmlinuz-2.4.17-grsec-1.9.3a-ow Kernel image. Then it is recom­mended to add it to the lilo menu:

sothis:/etc# vim lilo.conf # Boot up Linux by default.

#

default=Linux

image=/boot/vmlinuz-2.2.18pre21 label=Linux read-only

image=/boot/vmlinuz-2.4.17-grsec-1.9.3a-ow

label=2417

read-only

We just have to run lilo, and that is it. Next time we boot, we will be able to choose this 2.4.17 patched Kernel.

sothis:/etc# lilo Added Linux [1]

Added 2417

sothis:/etc#

8.3   Compile time protection: installing Stack Shield

This is a tool designed to add a protection level at compile time, on Linux i386 platforms. Your compiler must be gcc. Find information about Stack Shield at: http://www.angelfire.com/sk/stackshield/

A huge advantage of Stack Shield is how easy and quick it is to install!

We download the tarball, extract the sources, type make, and that is almost it... At that stage, we have built three binaries (stackshield, shieldg++ and shieldgcc), in the bin directory of the archive.

Now, we only have to add this directory to our path; for instance, if it has been installed in /opt/stackshield-0.7, we will type:

glaume@dante:/opt/stackshield-0.7$ export PATH=$PATH:/opt/stackshield-0.7/bin

A better solution consists in adding this directory to our path in a config file.

To use it, we compile our programs using shieldgcc instead of gcc, and shieldg++ instead of g++.

8.4   Intrusion Detection System: installing Prelude

We have already seen the Prelude principle and its main interests (see 7.2.1). Here is how to install it.

I would suggest to prefer the CVS tree version to the tarball, as it is much more up to date, although unstable...

The Prelude project is available on Sourceforge (http://sourceforge.net/projects/prelude/). Note that we need only three modules among the several we can see there, which are: libprelude, prelude-report and prelude-nids. Here is the information to get them from the CVS tree:

cvs -d:pserver:anonymous@cvs.prelude.sourceforge.net:/cvsroot/prelude login

cvs -z3 -d:pserver:anonymous@cvs.prelude.sourceforge.net:/cvsroot/prelude co modulename

We must install libprelude first, and then prelude-report and prelude-nids. For each one, follow these steps:

• enter the source directory

• type ./autogen-sh

• type ./configure with the appropriate options

• type make and make install

As we work on an unstable version here, we may experiment some difficulties, but this should work without too much trouble! Moreover, support and information are available on the website.

Now we need to configure MySQL to work with Prelude: we are using the prelude.sql script, available on the Prelude web page (Documentation unstable section). This script creates the tables required, so we must have a Prelude-dedicated database before executing it.

To be able to run prelude, we must register a user to let the nids communicate with the manager. This is done thanks to manager-adduser and sensor-adduser, we just follow the instructions.

At this stage, Prelude is ready to be run on our machine.

---