Linux-kernel mailing list archive 2000-23,: Re: OS stopping stack buffer overflow exploits

# Re: OS stopping stack buffer overflow exploits

Florian Weimer (fw@deneb.cygnus.argh.org)
04 Jun 2000 17:07:01 +0200

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Andi Kleen: "Re: [PATCH] fix for sysinfo(2) in 2.4.0-test1"
- Previous message: Myrddin Ambrosius: "IGMP"
- In reply to: Peter T. Breuer: "Re: OS stopping stack buffer overflow exploits"
- Next in thread: Jamie Lokier: "Re: OS stopping stack buffer overflow exploits"

"Peter T. Breuer" <ptb@it.uc3m.es> writes:

> > > And I have no idea why they should want to: nesting is purely a
> > > question of namespaces and syntactic scoping. It should impact
> > > the implementation semantics not at all.
> > Yes, that's right. That's why we need trampolines: otherwise, pointers
> > to nested functions would have semantics differing from ordinary function
> > pointers.
>
> Why so?

Please read the paper:

| In order to implement nesting and lexical closures in C++, we
| have to introduce a static link chain that links each activation
| record to the correct activation record for the lexically enclosing
| function (see [AU79] and [Wir77] for terminology). When we invoke
| a function, we not only have to know its address, but we also have
| to pass along a pointer to the correct activation record for the
| lexically enclosing function.

I've put a copy at:

http://cert.uni-stuttgart.de/people/fw/Usenix88-lexic.pdf

> When we do the call the return address gets pushed and we jump
> to the pointer.

No, it's different.

> 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
which looks like the correct one? This is horrible slow and breaks if
there's recursion (like many if not all if the static approaches).

-
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/

- Next message: Andi Kleen: "Re: [PATCH] fix for sysinfo(2) in 2.4.0-test1"
- Previous message: Myrddin Ambrosius: "IGMP"
- In reply to: Peter T. Breuer: "Re: OS stopping stack buffer overflow exploits"
- Next in thread: Jamie Lokier: "Re: OS stopping stack buffer overflow exploits"