Message-ID: <425C78AF.17778.10D9753E@localhost>
Date: Wed Apr 13 01:43:18 2005
From: pageexec at freemail.hu (pageexec@...email.hu)
Subject: linux bugs (survival stories)?

Valdis Kletnieks wrote:
> Now, going with specifics...  The last really big "trivial" issue with
> bypassing noexec on mounted filesystems was closed by a patch from Ulrich
> Drepper in 2.6.0 - basically forcing you to mmap() the binary in and then
> mprotect() it to add the exec flag.  And at *that* point, it gets ugly,
> because even if you stop them from calling mprotect() to get it
> executable, they can still use some variant of "unexec()" (see the
> Emacs/XEmacs source tree) to dump it out, twiddle the headers, and then
> exec() it off some other file system.

the problem with the above is that it assumes that you already have
a file system where you can write to/execute from, in which case
you don't need to bother with the original noexec mounted filesystem
at all, you just put your exploit into this fs and be done with it.

the real problem with the current linux noexec mount handling is
that by not restricting mprotect one can just construct an ELF file
that when mmap'ed will overlap the stack and call mprotect and
execute your code, effectively circumventing this measure (there was
a longish thread on this topic last May on dailydave), this gives
you a false sense of security only, not security. without such a
restriction a sysadmin cannot enforce a W^X policy at the file
system level. NetBSD (maybe the others as well, i didn't check)
and PaX both forbid mprotect(PROT_EXEC) on noexec mounts for this
reason.

Powered by blists - more mailing lists