lkml.org 
[lkml]   [1997]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectexecutable stacks, a few suggetions

On Mon, 14 Apr 1997, David S. Miller wrote:

> When you say "those executing code on the stack will have stack
> execution permission automatically enabled" you do realize that any
> program which has a signal delivered to it will "execute code on the
> stack" via the kernel itself? Since just about every program I know
> of which is of any utility takes a signal now and then during normal
> operation, doesn't this turn off your protection in enough cases to
> make it of little use?

plus anyone caring to exploit a setuid root executable buffer overflow
flaw can send bogus signals to get the protection turned off.

ok, this one can be circumvented by ignoring >all< signals. Thus the point
is the following: if this patch is used, AND the executable disables
signals, then buffer overflows are less dangerous. [maybe the point is
that most setuid root executables ignore signals already?]

but then >every< executable takes one more fault (which turns executable
stacks on), which isnt too cool performancewise.

i would suggest to turn executable stack off only for setuid exec()'s
only. Maybe this latter one is the coolest? exec()-ing takes sooo much
time anyways, these few instructions are lost in the noise [and they are
only needed for those few setuid programs]. (and admittedly, buffer
overflows are a major pain, and i would love seeing them reduced)

for setuid root processes i would even install a bit more code, just to
make them more secure: after a signal handler returns, i would turn off
execution bits again. Maybe there are a few more cases where execution
bits can be turned off again. >maybe<. The major idea is to check for
setuid executables at exec() time [we have that branch already].

-- mingo


\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.210 / U:0.636 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site