[14807] in bugtraq
Re: Solaris 7 x86 lpset exploit.
daemon@ATHENA.MIT.EDU (Peter da Silva)
Sat May 6 16:19:05 2000
Message-Id: <200005041909.OAA0000024698@grendel.eng.baileynm.com>
Date: Thu, 4 May 2000 14:09:58 -0500
Reply-To: Peter da Silva <peter@GRENDEL.ENG.BAILEYNM.COM>
From: Peter da Silva <peter@GRENDEL.ENG.BAILEYNM.COM>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <200005030604.CAA01307@twig.rodents.montreal.qc.ca>
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.
