Date: 4 May 2003 15:24:05 -0000
Message-ID: <20030504152405.7501.qmail@science.horizon.com>
From: linux@horizon.com
To: Valdis.Kletnieks@vt.edu
Subject: Re: [Announcement] "Exec Shield", new Linux security feature
Cc: linux-kernel@vger.kernel.org
In-Reply-To: <200305032300.h43N0UX9006675@turing-police.cc.vt.edu>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2495
Lines: 62

On Sat, 03 May 2003 13:19:52 -0000, linux@horizon.com  said:
> An interesting question arises: is the number of useful interpreter
> functions (system, popen, exec*) sufficiently low that they could be
> removed from libc.so entirely and only staticly linked, so processes
> that didn't use them wouldn't even have them in their address space,
> and ones that did would have them at less predictible addresses?
> 
> Right now, I'm thinking only of functions that end up calling execve();
> are there any other sufficiently powerful interpreters hiding in common
> system libraries?  regexec()?

To which Valdis.Kletnieks replied:
> This does absolutely nothing to stop an exploit from providing its own
> inline version of execve().  There's nothing in libc that a process can't
> do itself, inline.

Ah, but with a non-executable stack, how do you arrange the inline code?
if you include it in the buffer overflow on the stack, it's in the
non-executable range.

You could arrange a return to memcpy(), with a stack like this:

[Address of memcpy()]
[Exploit target address (return address from memcpy)]
[Exploit target address (destination of memcpy)]
[Address of code on stack (source of memcpy)]
[Length of code on stack]
[Exploit code]

This would work if you had an "exploit target address" that was
writeable and executable, which this could copy the code to, but that's
hard to come by.

Now, we could stick a call to mprotect on the stack before that, but
it's hard to get the protection flags past the kernel test:

mm/mprotect.c, like 237:
        if (prot & ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM))
                return -EINVAL;

When your exploit can't include any null bytes.


Arjan's idea about a CAP_EXEC would be better, if it could be dropped
automagically by linker magic on existing code.

In fact, there are several other capabilities that would be nice to
have droppable:

- Ability to open an existing regular file or device (seekable,
  persistent storage) for writing.  An SMTP daemon could probably
  drop this.
- Ability to create an externally accessible listening socket
  (listen() on non-PF_UNIX)
- Ability to connect to an external address (connect() on non-PF_UNIX)

The PF_UNIX exception is for /dev/log.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/