Subject: Re: Code on stack (Re: exploit with memcpy())
To: TAMURA Kent <kent@netbsd.org>
From: None <xs@kittenz.org>
List: tech-userlevel
Date: 07/04/2002 09:49:06
on Thu, Jul 04, 2002 at 01:50:12PM +0900, TAMURA Kent wrote:
> > That is precisely one of the reasons I'm working on my signals changes.
> 
> It is interesting.
> I have heard gcc generates trampoline code on stack in some cases.

gcc trampolines are not often used, and when they are it is possible to
detect them and allow them to work. The Openwall patch for linux does
this. It's MD though and probably error prone. I think it is also used
to detect and permit signal trampolines in some cases too.

> I guess many exploit code calls syscalls directly, that is "int
> $0x80" in i386.  To prohibit calling syscalls from stack code
> would be sufficient.

You can still cause a lot of damage without calling any syscalls from the
stack. For example, you could push sufficient parameters onto the stack
to make a successful call to system(), write to mmaped regions, etc.

Alternatively just overwrite the stored pc with the address of a fragment
of code in some library or program function that will run /bin/sh for you,
a non-executable stack will not stop that.

http://pageexec.virtualave.net/ has some interesting ideas on dealing
with return into libc type problems, namely address space randomization.