Full Disclosure mailing list archives
Re: Linux Exec Shield (was: Linux (in)security)
From: Peter Busser <peter () adamantix org>
Date: Thu, 23 Oct 2003 14:39:08 +0200
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 () adamantix 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/ _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- RE: [inbox] Re: RE: Linux (in)security, (continued)
- RE: [inbox] Re: RE: Linux (in)security Arcturus (Oct 23)
- Re: [inbox] Re: RE: Linux (in)security Peter Busser (Oct 24)
- Re: [inbox] Re: RE: Linux (in)security Shawn McMahon (Oct 24)
- Re: [inbox] Re: Linux (in)security Chris Ruvolo (Oct 24)
- Re: [inbox] Re: RE: Linux (in)security Valdis . Kletnieks (Oct 24)
- Re: [inbox] Re: RE: Linux (in)security Henning Brauer (Oct 30)
- Re: RE: Linux (in)security Ron DuFresne (Oct 23)
- Re: RE: Linux (in)security Peter Busser (Oct 23)
- Re: RE: Linux (in)security Ron DuFresne (Oct 23)
- Linux Exec Shield (was: Linux (in)security) Chris Ruvolo (Oct 23)
- Re: Linux Exec Shield (was: Linux (in)security) Peter Busser (Oct 23)
- Re: Linux Exec Shield (was: Linux (in)security) Arjan van de Ven (Oct 23)
- Re: Linux Exec Shield (was: Linux (in)security) Chris Ruvolo (Oct 24)
- Re: RE: Linux (in)security I.R. van Dongen (Oct 22)
- Re: RE: Linux (in)security Robert Brockway (Oct 22)
- Re: RE: Linux (in)security madsaxon (Oct 23)
- Re: RE: Linux (in)security Ron DuFresne (Oct 23)
- Re: RE: Linux (in)security Paul Schmehl (Oct 23)