[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE: Secure 2.4.x kernel



Well hello list, 

it could be, that i'm overstepping my knowledge (and my english).

If i have well understood, one of the problems of bufferoverruns is 
the follwing:

The assembly statement "jsr" (jump to subroutine) puts the return address
on the same stack, where space for local variables is reserved.

So one solution is to seperate these stacks. So it's more a "problem"
of the  C-Compiler (and the number of Address-Register of the CPU and
memory).


So my questions are :

1) Is my problem description right ?
2) On other plattforms (for example on the newer plattforms like ia64)
   are there seperate stacks ?
3) Why is this not done on  the "0x86"-Plattform ?
   (Historical Reasons ? No chance of a step by step migration 
    because of the interplay between programms and libarys ?)







On Fri, 21 Dec 2001, Kelly Martin wrote:

> > Hmmm I don't buy that this *couldn't* be done on the Intel.
> > I might be overstepping my knowledge, but I'm sure there
> > *must* be a way.
> 
> > Going back to my 68k days, it would have been fairly easy
> > to write this. Hey, I'm not an Intel assembly/opcode expert,
> > but it seems to me, I think that you could sit something right
> > in on an interrupt that would alert when a fork/exec call
> > was being made -- it wouldn't take a rocket scientist to
> > figure out that if you could take an interrupt/event on
> > this type of sig, you could certainly redirect the behavior
> > or outcome.
> 
> You've misunderstood.  I was stating that it would be hard to _protect the
> stack against overruns_ on the Intel platform.  What you're talking about
> has nothing to do stack protection.  Fork and exec (being syscalls) are
> already handled as software interrupts, so what you're talking about doing
> is what the kernel already does.
> 
> > The examples pointed out (electric fence, st. james etc.) are
> > fine "workarounds", but they all look a little too "patch-like"
> > for it to be something that is "industrial strength".
> > I just think that intercepting the syscalls like fork and exec
> > at the kernel level for anything that is not "privy" should
> > be a feature of the kernel.
> 
> Statements like this lead me to question whether you really know what you're
> talking about.  Electric Fence is a tool for debugging heap overruns and has
> nothing to do with access control in the kernel.  St. Jude is _exactly_ what
> you're claiming is necessary: it's a tool for intercepting syscalls at the
> kernel level.  And, to be honest, where the hell else would you intercept a
> syscall?
> 
> Kelly
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-security-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> 
> 



Reply to: