With the non-executable stack kernel, how can I make stack executable
on demand? If I set kernel with non-executable stack, only those
binaries marked with executable PT_GNU_STACK will have executable
stack. But a binary with non-executable PT_GNU_STACK may dlopen a
DSO with executable PT_GNU_STACK. The dynamic linker will try to
make stack executable with mprotect. But it will either fail if
kernel is set with non-executable stack, or be a no-op if kernel
is set with executable stack. Is there a third option that a process
starts with non-executable stack and can change the stack permission
later?
H.J.
H. J. Lu wrote:
> is set with executable stack. Is there a third option that a process
> starts with non-executable stack and can change the stack permission
> later?
>
Well, in my opinion your request is equivalent to "keep all these cute
buffer overflows forever". Take any protected app, LD_PRELOAD or drop in
a bad/malicious library and your're done for good. Not really a good idea.
--
Andreas Steinmetz SPAMmers use [email protected]
On Fri, Apr 16, 2004 at 08:07:30PM +0200, Andreas Steinmetz wrote:
> H. J. Lu wrote:
> >is set with executable stack. Is there a third option that a process
> >starts with non-executable stack and can change the stack permission
> >later?
> >
>
> Well, in my opinion your request is equivalent to "keep all these cute
> buffer overflows forever". Take any protected app, LD_PRELOAD or drop in
> a bad/malicious library and your're done for good. Not really a good idea.
The current scheme doesn't work too well. Linker doesn't combine
PT_GNU_STACK from DSO:
http://sources.redhat.com/ml/binutils/2004-04/msg00341.html
for a reason. It expects the dynamic linker to do that at the run-time,
which kernel won't allow. I am looking for a reasonable solution.
H.J.
> But it will either fail if
> kernel is set with non-executable stack,
eh no. mprotect with prot_exec is still supposed to work. The stacks
still have MAY_EXEC attribute, just not the actual EXEC attribute
On Fri, Apr 16, 2004 at 10:02:58PM +0200, Arjan van de Ven wrote:
> > But it will either fail if
> > kernel is set with non-executable stack,
>
> eh no. mprotect with prot_exec is still supposed to work. The stacks
> still have MAY_EXEC attribute, just not the actual EXEC attribute
Ok. It looks like a bug in Red Hat EL 3 kernel. In fs/exec.c, there
are
if (executable_stack)
mpnt->vm_flags = VM_STACK_FLAGS | VM_MAYEXEC | VM_EXEC;
else
mpnt->vm_flags = VM_STACK_FLAGS & ~(VM_MAYEXEC|VM_EXEC);
That is if an executabl is not marked with executable stack, the
VM_MAYEXEC bit is turned off. But 2.6.5-mm6 has
if (unlikely(executable_stack == EXSTACK_ENABLE_X))
mpnt->vm_flags = VM_STACK_FLAGS | VM_EXEC;
else if (executable_stack == EXSTACK_DISABLE_X)
mpnt->vm_flags = VM_STACK_FLAGS & ~VM_EXEC;
else
mpnt->vm_flags = VM_STACK_FLAGS;
The VM_MAYEXEC bit is untouched. Now the question is if it is a good
idea for user to change stack permission.
H.J.
On Fri, Apr 16, 2004 at 01:46:51PM -0700, H. J. Lu wrote:
> On Fri, Apr 16, 2004 at 10:02:58PM +0200, Arjan van de Ven wrote:
> > > But it will either fail if
> > > kernel is set with non-executable stack,
> >
> > eh no. mprotect with prot_exec is still supposed to work. The stacks
> > still have MAY_EXEC attribute, just not the actual EXEC attribute
>
> Ok. It looks like a bug in Red Hat EL 3 kernel. In fs/exec.c, there
That version of exec-shield is quite dated. For the latest version,
look on http://people.redhat.com/mingo, or the Fedora kernels.
I'm pretty sure that Exec-shield isn't even enabled in the EL kernels
at this time, so it's quite out of date in respect to the others.
Dave
On Fri, Apr 16, 2004 at 01:46:51PM -0700, H. J. Lu wrote:
> On Fri, Apr 16, 2004 at 10:02:58PM +0200, Arjan van de Ven wrote:
> > > But it will either fail if
> > > kernel is set with non-executable stack,
> >
> > eh no. mprotect with prot_exec is still supposed to work. The stacks
> > still have MAY_EXEC attribute, just not the actual EXEC attribute
>
> Ok. It looks like a bug in Red Hat EL 3 kernel. In fs/exec.c, there
> are
>
> if (executable_stack)
> mpnt->vm_flags = VM_STACK_FLAGS | VM_MAYEXEC | VM_EXEC;
> else
> mpnt->vm_flags = VM_STACK_FLAGS & ~(VM_MAYEXEC|VM_EXEC);
yep that's a bug
> The VM_MAYEXEC bit is untouched. Now the question is if it is a good
> idea for user to change stack permission.
it's required for correct operation and "security wise" it doesn't matter,
if someone can execute an mprotect syscall the game is over anyway
H. J. Lu wrote:
> On Fri, Apr 16, 2004 at 10:02:58PM +0200, Arjan van de Ven wrote:
> > > But it will either fail if
> > > kernel is set with non-executable stack,
> >
> > eh no. mprotect with prot_exec is still supposed to work. The stacks
> > still have MAY_EXEC attribute, just not the actual EXEC attribute
>
> [...]
> The VM_MAYEXEC bit is untouched. Now the question is if it is a good
> idea for user to change stack permission.
You can create a new executable data area with mmap(), copy the stack
to it, unmap the stack, and mremap() to move the copy to where the
stack was. The run time linker can do this if you're on a kernel
where mprotect() fails.
In other words, even those kernels which disable VM_MAYEXEC don't
protect against this alternative way of simulating mprotect(). There
is no point in them prohibiting it.
-- Jamie
Hi!
> >is set with executable stack. Is there a third option that a process
> >starts with non-executable stack and can change the stack permission
> >later?
> >
>
> Well, in my opinion your request is equivalent to "keep all these
> cute buffer overflows forever". Take any protected app, LD_PRELOAD or
> drop in a bad/malicious library and your're done for good. Not really
> a good idea.
With malicious libraries, you have *way* bigger problems than
buffer overruns.
Pavel
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms