Re: SMASHING THE STACK: PREVENTION?

Alex Belits (abelits@phobos.illtel.denver.co.us)
Mon, 28 Apr 1997 19:17:46 -0700

> For all I know there are very few SUID 0 programs which invoke execXXX
> routines to spawn a shell. Getty is probably the only significant SUID program
> which starts a shell, so it should be pretty easy to introduce additional
> checks: for instance if the SUID program tries to exec any of the shells: csh,
> bash, ksh,...., just returns an error and logs the real_user_id somewhere.
>
> Any comment?

cp /bin/sh whatever

IMHO all those checks can result only in more confusion for a programmer
and almost unnoticeable trouble for intruder. Even non-executable stack
will be useless because it will just cause exploits to place shellcode
somewhere else, and even making everything non-executable except
actual code can't guarantee anything because a lot of suid programs, as it
was mentioned before, have code suitable for intruder's needs already. I
see only three solutions:

1. (obvious) Fix the code. Probably will take a lot of time, but should be
done anyway.

2. Reduce the amount of suid root code. sendmail and xlock have absolutely
no need to run as a single large piece of code that keeps root privileges
all the time and can be started by any user. They can be easily split into
large and possibly not thoroughly buffer-checked part and small secure
setuid program that will do only what supposed to be done as root. wtmp is
also ridiculous reason to be setuid root, xterm can just fine be split
into terminal/login handler that will be set{u|g}id to tty (or whatever
but root/wheel) and vt100/tek emulator. ps and friends can follow linux
example and use /proc that shouldn't be too hard to implement in any
system, and only things like ping and su can't be changed that way, but
those ones aren't hard to make secure anyway (AFAIK, they already are well
written everywhere).

3. Some mechanism to increase privileges for certain parts of code in
certain executables. Should be really hard and will require modification
of the kernel and use of some authentication mechanism in it, so some
setuid utility (modified linker?) will start, authenticate itself with the
kernel, and then kernel will allow that process to change its uid/gid
between some set of uids/gids from some parts of code or only from some
libraries, so whatever will be exec'ed by that utility, will keep that
ability until the next exec or exit that will invalidate such privilege.
It still will be possible to feed something to that program so privileged
code will do something "wrong" if it isn't designed to be secure, but in
that case security will depend mostly on privileged routines, not on
everything around equally.

--
Alex