Re: OS stopping stack buffer overflow exploits

From: Peter T. Breuer (ptb@it.uc3m.es)
Date: Sun Jun 04 2000 - 10:20:22 EST


"A month of sundays ago Florian Weimer wrote:"
> "Peter T. Breuer" <ptb@it.uc3m.es> writes:
> I've put a copy at:
>
> http://cert.uni-stuttgart.de/people/fw/Usenix88-lexic.pdf

If you could put up an ascii copy, that would be helpful right now.

> > When we do the call the return address gets pushed and we jump
> > to the pointer.
> No, it's different.

Well, whatever you do, you do it. The point is that you do something
with the stack that is determined at compile time. So you can calculate
the reference and dereference strategy at compile time too.

> > It references locations in its frame on the stack for its
> > local variables, and locations higher up the stack for the enclosing
> > functions variables.
>
> How do you do that if the call of the nested function is itself nested
> in another function? Unwind the stack until you get a stack frame

Nested nests make no difference. If the twice-nested function really
references variables in its grandfather, that's simply a bigger offset
up the stack.

> which looks like the correct one? This is horrible slow and breaks if

You are talking about what happens say when f calls f calls f calls f
... and still references variables in the parents scope. Then at each
recursion the parents scope is further and further above it on the
stack. OK. I agree. You need to count the number of times f has been
called without the parent having been called between-times and adjust
the references to the parents variables accordingly at each recursion.
Or, say, you need to pass a pointer to the parents stack frame
into each invocation of the nested function. I'd do that. It parallels
the way OO methods pass a reference to this or super.

> there's recursion (like many if not all if the static approaches).

Peter

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:18 EST