Date: 10 Feb 1997 11:59:41 -0000 From: tqbf@enteract.com To: dufault@hda.com, freebsd-security@freebsd.org Subject: Re: buffer overruns Message-ID: <19970210115941.27807.qmail@char-star.rdist.org> In-Reply-To: <199702100954.EAA08773@hda.hda.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <199702100954.EAA08773@hda.hda.com>, you wrote:
>Is the stack executable? I've been assuming the exploits modify
Yes.
>the stack to return to a built up call to "system" or something
system() is a library routine that decays to an execve() (which is a
system call) of /bin/sh with arguments indicating the command line to be
run. There's no guarantee that system() will even be accessible from any
given program, let alone that it'll be at some fixed address. System calls
are always accessed the same way (on FreeBSD, either lcall(7,0) or int
80h).
>else in the library with their own args setup. I've been assuming
>that executing data isn't part of modern exploits.
You're assuming that the exploits overwrite the return address to point to
system("/bin/sh"), and some how manipulate the stack to have the correct
arguments. They don't. Stack ovverun exploits overwrite the return address
to point to some region of memory (usually the stack) that the attacker
has control over; the attacker ensures that that area of memory contains
executable opcodes that will do what the attacker wants (usually
execve()'ing a shell).
>Has anyone seen modifications to gcc to generate guard bands around
>automatics and stack check sequences? The automatics can be checked
On SunOS, yep. It broke alot of things we tried compiling.
--
----------------
Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com]
----------------
exit(main(kfp->kargc, argv, environ));
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970210115941.27807.qmail>