Re: Solaris 7 x86 lpset exploit.

[peter () GRENDEL ENG BAILEYNM COM (Peter da Silva)]

In article <200005030604.CAA01307 () twig rodents montreal qc ca>,
der Mouse  <mouse () RODENTS MONTREAL QC CA> wrote:
> > > Another possible way around it would be to cause gcc to keep part of
> > > the stack in the data segment, out of what the kernel thinks of as
> > > the stack, and have it do its trampolines there.  This runs into big
> > > problems with setjmp and other nonlocal exits, and possibly with
> > > signal handlers as well.

> > You could handle that by having a frame pointer on the processor
> > stack point into the function's executable stack frame (if it has
> > one) on the trampoline stack, rather than having a permanent stack
> > pointer into this space.  I don't think there would be any issues
> > with this, unless you're trying to use setjmp/longjmp for coroutines
> > or something perverse like that.

> If you longjmp out, how do you free up the jumped-through frames on the
> executable stack?

If the frame pointer only exists on the processor stack what is there to
free up?

> If you do it by using a contiguous executable stack
> with an offset-style pointer into it, conceptually the way longjmp
> deals with freeing ordinary stack frames, how do you deal with
> overflow, without wasting large amounts of data segment space on
> programs that don't need deep executable stacks?

How big a stack are you thinking of? How big are the chunks of code you're
allocating on it? I was under the impression that these are 20-30 byte chunks
of code at the most... suppose you allocated a megabyte of address space to
the task, would any modern system even notice? Would you ever overflow?

Even on 32-bit operating systems allocating a gigabyte or so of address space
to system code isn't a big deal...  on 64-bit... well, Tru64 UNIX starts
memory allocations above the first gigabyte to try and make sure you trap
when following bogus pointers.

> If you do it with a
> linked list of frame structures, how do you push frames on it without
> risking either a corrupted stack or a lost frame in the presence of
> longjmp out of a signal handler?  If you do it with something else,
> well, what?

You can always do it in the exit or entry code of any routine that uses the
executable stack. The only serious failure mode I can see for that is pretty
unlikely... you'd have to have a program do a bunch of executable stack work,
longjmp out of ALL of it, then never touch the executable stack for the rest
of the program.