Re: [Full-Disclosure] Linux Exec Shield (was: Linux (in)security)

From: Peter Busser (peter_at_adamantix.org)
Date: 10/23/03

  • Next message: Brian Hatch: "Re: [Full-Disclosure] Re: Gaim festival plugin exploit"
    To: full-disclosure@lists.netsys.com
    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
    

  • Next message: Brian Hatch: "Re: [Full-Disclosure] Re: Gaim festival plugin exploit"

    Relevant Pages

    • [Full-Disclosure] Linux ELF loader vulnerabilities
      ... Numerous bugs have been found in the Linux ELF binary loader while ... Internally the Linux kernel uses a binary format loader layer to ... and the position of the memory map header in the binary image and ... An user may try to execute such a malicious binary with an unterminated ...
      (Full-Disclosure)
    • Linux ELF loader vulnerabilities
      ... Numerous bugs have been found in the Linux ELF binary loader while ... Internally the Linux kernel uses a binary format loader layer to ... and the position of the memory map header in the binary image and ... An user may try to execute such a malicious binary with an unterminated ...
      (Full-Disclosure)
    • Linux ELF loader vulnerabilities
      ... Numerous bugs have been found in the Linux ELF binary loader while ... Internally the Linux kernel uses a binary format loader layer to ... and the position of the memory map header in the binary image and ... An user may try to execute such a malicious binary with an unterminated ...
      (Bugtraq)
    • Re: [Full-disclosure] Linux Kernel CIFS Vulnerability
      ... As for the ASLR component of PageExec: in kernel space, ... soon to issue from the varied and sundry organisations who bundle the Linux ... the reason is intersintg too; linus considers security ... lot of bug classes from the start, ...
      (Full-Disclosure)
    • Re: [Full-disclosure] Fwd: ipv6 flaw (is bullshit)
      ... sure a quick talk with Eugene from the Red Hat Linux corporation (he ... browser exploit hackers in the world, I do not do kernel bugs. ... If someone in Goatse Security were to be involved with the ... I have also talked with reporters at ZDnet previously, ...
      (Full-Disclosure)