some PaX Q&A

[PaX <pageexec () FREEMAIL HU>]

firts of all, thanks for the feedback, and excuse us for not
addressing everyone personally, but we'll try to answer some
questions you have raised in general.

1. before anything, please take a look at the following URL,
it already clarifies some points:

http://securitygeeks.shmoo.com/article.php?story=20001031052646219#comments

2. 'unique solution' thread: PaX is *NOT* the ultimate
solution against buffer overflow based exploits (sorry if we
made it sound like that), what it does (implementing the
PAGE_EXEC feature) however reduces the ways such an overflow
can be (ab)used
by an attacker. namely, only already existing executable
code (in the given tasks's
address space) can be executed, but *NEVER* the payload (as
long as no
read/write/exec pages exist in the task, which is normally
the case, except that in
the current implementation shared memory pages are created
read/write/exec, as
soon as someone ensures us that exec is indeed unnecessary,
we'll remove it).
it does not matter how the attacker sets up the overflowed
stack to get his payload
copied all around in the  tasks' address space, he will
never get to execute it.  this
in our opinion is a significant progress already. so, let's
address the remaining way
for exploits (of which the 'return to libc' method is one
example) next.

3. 'return to libc' thread: now that our attacker has left
no choice but to try issue calls
to existing code in the tasks's address space, our next goal
will have to be to
reduce his chances at doing this. the idea we've come up
with is a very simple
authentication mechanism, which - much like stackguard,
propolice and the like -
requires recompilation of applications. without further ado,
let's take an assembly
level example (where everything ends up eventually).
hopefully the intel/nasm syntax
will cause no problems (remember that args are in dest/src
order).

   segment .data
     libc_func_flag: dd 0

   segment .text
   some_user_app_func:
       mov dword [libc_func_flag],1
       ... push args on the stack for call...
       call libc_func
       mov dword [libc_func_flag],0
       ....

    libc_func:
        ... move args from stack to registers for int
0x80...
        cmp dword [libc_func_flag], 1
        jz .1

        ... refuse call, crash/exit//log/etc...

    .1: int 0x80
        ... do the rest ...
        retn

with this flag system the attacker can still attempt to
execute existing code, but he
will either fail (when directly attempts to call libc_func)
or succeed, but args will be
taken from the app instead of from his payload (when
returning to
some_user_app_func). if you combine this method with
propolice/stackguard and
the like (plus PaX), you will end up with a system in which
finding *exploitable*
buffer overflows will become very hard (if you have reverse
engineering experience,
you will know why). it won't become impossible, but very
special circumstances will
be required.

4. 'relation to openwall' thread: PaX implements more than
what solar designer's
non-executable stack does (PaX protects any and all pages
that are created
without the PAGE_EXEC flag). therefore it is our hope that
even if PaX does not
make it into the mainstream kernel (there are arguments
indeed that 'regular' users
would not need such a feature), openwall and similar
initiatives will embrace it.