OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: Solaris 7 x86 lpset exploit.
From: Peter da Silva (peterGRENDEL.ENG.BAILEYNM.COM)
Date: Thu May 04 2000 - 14:09:58 CDT

In article <200005030604.CAA01307twig.rodents.montreal.qc.ca>,
der Mouse <mouseRODENTS.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.