Message-ID: <20031023123908.GA8661@adamantix.org>
From: peter at adamantix.org (Peter Busser)
Subject: Linux Exec Shield (was: Linux (in)security)

Hi!

On Wed, Oct 22, 2003 at 03:27:17PM -0700, Chris Ruvolo wrote:
> On Wed, Oct 22, 2003 at 10:16:02AM -0700, Edward W. Ray wrote:
> > Linux is the hands of someone with no interest or regard for security is the
> > same as Windows or any other OS in the hands of the same clueless
> > individual.  The main difference between the Linux and Unix variants (i.e.
> > BSD, Solaris, HP-UX) is that they have already learned their lesson regarded
> > buffer overflows and kernel hardening and allowed the user more control in
> > securing their systems.  M$ has not, and that is unfortunate.
> 
> Speaking about kernel hardening, I was wondering if anyone on the list could
> comment on Ingo Molnar's Exec Shield Linux kernel patches.

You can find out the facts for yourself by running paxtest. Paxtest can be
obtained from the PaX homepage at: http://pageexec.virtualave.net/. The latest
version is v0.9.4, which should be available from there soon. In the meantime,
you can download it from http://mail.adamantix.org/paxtest-0.9.4.tar.gz.

Unpack, make generic and ./paxtest. The results will be displayed on screen and
written to paxtest.log (the screen tends to get clutered when running this test
on a PaX enabled kernel :-).

This is what it looks like when you run it on an Adamantix kernel:

PaXtest - Copyright(c) 2003 by Peter Busser <peter@...mantix.org>
Released under the GNU Public Licence version 2 or later

Executable anonymous mapping             : Killed
Executable bss                           : Killed
Executable data                          : Killed
Executable heap                          : Killed
Executable stack                         : Killed
Executable anonymous mapping (mprotect)  : Killed
Executable bss (mprotect)                : Killed
Executable data (mprotect)               : Killed
Executable heap (mprotect)               : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Executable stack (mprotect)              : Killed
Anonymous mapping randomisation test     : 16 bits (guessed)
Heap randomisation test (ET_EXEC)        : 13 bits (guessed)
Heap randomisation test (ET_DYN)         : 25 bits (guessed)
Main executable randomisation (ET_EXEC)  : No randomisation
Main executable randomisation (ET_DYN)   : 17 bits (guessed)
Shared library randomisation test        : 16 bits (guessed)
Stack randomisation test (SEGMEXEC)      : 23 bits (guessed)
Stack randomisation test (PAGEEXEC)      : 24 bits (guessed)
Return to function (strcpy)              : Vulnerable
Return to function (strcpy, RANDEXEC)    : Vulnerable
Return to function (memcpy)              : Vulnerable
Return to function (memcpy, RANDEXEC)    : Vulnerable
Executable shared library bss            : Killed
Executable shared library data           : Killed
Writable text segments                   : Killed

Each line is printed by a program which tries to do a ``funny thing'' with its
memory. The ``Executable ...'' tests basically put an instruction in a place
that is supposed to be data (i.e. malloced data, C variable, etc.) and tries to
execute it. The ``(mprotect)'' tests try to trick the kernel in marking this
piece of memory as executable first. Return to function tests overwrite the
return address on the stack, these are hard to prevent from inside the kernel.
The last test tries to overwrite memory which is marked as executable.

PaX is able to randomise the address space layout. Everytime you load a shared
library, it will be loaded at a different address. The range of randomisation
is measured by the randomisation tests.

A normal Linux kernel will show all tests as Vulnerable and no stack
randomisation or 6 bits (due to stack colouring). In other words, on a normal
Linux kernel you can execute any data inside a process's memory or overwrite
any code at will.

> How effective do you think they are?  Would it actually make some holes more
> difficult to exploit?  Impossible to exploit?  Obviously its not a 100%
> blanket protection against buffer overflows (as acknowledged by the author),
> but does anyone here think it could be worthwhile?

I ran these test programs on the new Red Hat Enterprise Linux beta (Taroon) and
the results are pretty disappointing. The default is only to enable the
randomisation functions. But you can add exec-shield=2 to the kernel command
line to turn on more checking and then it will kill some of the test programs,
but not all of them.

What I don't like about exec-shield, is that it is based on a few assumptions.
One of the assumptions is that stack overflows are only possible with ASCII
data (which is what the ASCII-shield refers to). As if memcpy() to a buffer
will never cause any overflows. If you run paxtest against exec-shield, you'll
see that it also doesn't cover all possibilities. From a security point of view
I don't understand why Red Hat would bother developing a kernel patch of their
own that duplicates only half of what an already existing patch (i.e. PaX does).
But I suspect that exec-shield is again a speed vs. security compromise that we
see more in the Linux world, because the overhead is claimed to be low. On the
other hand, it is nice that one distribution maker at least spends some effort
on security improvement.

The effectiveness remains to be seen. In the short term, using something like
PaX is certainly effective, as can be seen here:
http://groups.google.com/groups?selm=20030525190037%2470c6%40gated-at.bofh.it

37 break ins in a year on normal Linux, 0 on a PaX kernel.

This is the reason why Adamantix ships PaX enabled kernels since before v0.9
was released almost a year ago.

On the long term, people will probably find ways around it. But it should raise
the bar and make it more difficult for some (but not all) remote exploits.

Fortunately, there are more measures that can be taken against overflows, and
break ins in general. Like the stack smashing protector (aka propolice) and
RSBAC. The first is already integrated in Adamantix, RSBAC is being worked on.

Groetjes,
Peter Busser
-- 
The Adamantix Project
Taking trustworthy software out of the labs, and into the real world
http://www.adamantix.org/

Powered by blists - more mailing lists