A security hole

[Stephen J. Friedl]

In article <478 at minya.UUCP>, jc at minya.UUCP (John Chambers) writes:
 > > [somebody else's stuff (sorry, deleted it)]
 > > First of all, by writing a setuid program you automatically open
 > > the security hole and you are likely to fall in. You must always
 > > be suspicious of any setuid program.
 >
 > Uh, I'm not sure I believe all this.  I mean, I understand why root should
 > never include "." or any world-writable directories in its search path.
 > Does your unspecified hole amount to anything more than this?  If so, you
 > aren't saying anything at all about getcwd() or popen(), just about search
 > paths.

You can never remind people enough about search paths because it
is so easy to mess up.  Also, it is not "obvious" that asking the
system for your current directory will fork another process while
doing so.  Set[ug]uid programs should do something like:

        putenv("PATH=/bin:/usr/bin:/etc");

early so the user's path is totally ignored no matter what the
rest of the program does.  Sometimes perhaps you can't do this
but in most cases it will help a lot.

 > This adds to my conviction that someone doesn't know what they're talking
 > about.  Do you perhaps mean "setuid-root"?  If so, you are of course correct.
 > If you don't understand my point, you don't know enough about Unix security
 > to pontificate on the subject.

Hold it.  If I find a breakable setuid program on a machine I
will get root eventually.  Example: if I break the "bin" group on
a machine where /bin is drwxrwxr-x (like my SVR3.1 3B2/400)  I can
replace /bin/ls with my own program.  My version will exec the
"real" ls but if root is the uid then it will do something
special for me.  Setuid/setgid *anything* is dangerous.

 > Also, I'm sure that I'm far from the only one who is getting tired of seeing
 > dire warnings like:
 >      The 'cc' command contains a MAJOR security hole; you should delete it
 >      from your system as fast as possible.  I can't tell you what the hole
 >      is, because it would allow any hacker to break into any Unix system in
 >      the world.  Believe me; I know what I'm talking about.
 > It's easy enough to make up warnings like these, but many of them turn out
 > on investigation to be full of bull; some are in fact fraudulent attempts
 > to discredit someone else's useful software.

We all hate them, partly because we would *love* to know what the
bug is (of course *we* would never misused this information).
Too bad there aren't good ways to fix the bugs without giving a
class in smashing systems.  The best you can do is consult your
friendly neighborhood security wizard and ask him/her about it.
They are perhaps more capable of evaluating the nature of the
threat.

 > Anyhow, what can one do with getcwd() or popen() within a setuid program
 > (root or otherwise) that isn't a consequence of the search path?  If there
 > is a real security hole here, I'd be very interested in reading about it.

Even if a program does

        system("/bin/pwd");

it can still be smashed, partially related to the search path.
See the last item on the list for the fix.

These rules have probably been posted a hundred times but I
don't mind doing it one more.

*    don't write setuid programs

*    if you must, don't make them setuid root.  Make them some
     new uid/gid that is not part of the system (avoid bin, sys,
     adm, etc.)

*    write setgid instead of setuid if you can

*    if the special access is in a limited area, write a separate
     program that does just that job and make the rest of the
     program non-set-anything.  Then have the main program call
     the setuid guy for the secure stuff.  Example: /bin/mv is
     normal but calls (setuid root) /usr/lib/mv_dir to move
     directories around.

*    open all your secure files early in the program, then do

         setuid(getuid());
         setgid(getgid());

     This turns off the setuid/setgid permissions and makes the
     program a normal peon user process again.  Remember, once a
     file is open permissions don't count any more.

*    if you must run set[ug]id all the time, write your own
     system() that does the previous item after the fork but
     before the exec.  This makes the child not have any special
     permissions. It doesn't always help if you need to exec
     a protected process in a protected areA, but it works in
     a lot of cases.

*    If your programs call popen or system, put the line

          putenv("IFS= \n\t");

     in it early.  This closes up a fairly obscure hole; read your
     /bin/sh manual if you are really interested in this.  Ask
     your local security wizard about this for more info.


     One thing about security is that there is always somebody
out there who knows more than you do, and all they need is one
bug that you didn't think of.  The above list is certainly not
all-inclusive, and the security wizards out there are welcome to
flame me (privately unless it is of general interest) if I blew
it on something.

     Steve
-- 
Life : Stephen J. Friedl @ V-Systems, Inc./Santa Ana, CA   *Hi Mom*
CSNet: friedl%vsi.uucp at kent.edu  ARPA: friedl%vsi.uucp at uunet.uu.net
uucp : {kentvax, uunet, attmail, ihnp4!amdcad!uport}!vsi!friedl