Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!apple!magic!vlb
From: vlb@magic.apple.com (Vicki Brown)
Newsgroups: comp.unix.questions
Subject: Re: Suid script security
Message-ID: <9689@goofy.Apple.COM>
Date: 10 Aug 90 19:41:32 GMT
Sender: usenet@Apple.COM
Reply-To: vlb@apple.COM (Vicki Brown)
Organization: Apple Computer
Lines: 80
Sender:


In article <14920003@hpdmd48.boi.hp.com> markw@hpdmd48.boi.hp.com (Mark Wolfe) writes:
>
>    I know that suid scripts are a bad idea from reading comp.questions and
>comp.wizards over the last year or so. It seems that just about every guru
>in the world has posted a warning NOT to do it, so I decided I would follow
>the advice (it's a rare subject that all guru's agree on). However, it appears
>that I'm now about to have one of these ugly animals forced on me from above,
>so I'd like some advice:
>
> 1)  Just what are the security risks involved? (i.e. how would someone attack
>     a system via one of these).
>
> 2)  What can I do to make this as secure as possible?

Warning - very long response ahead.  Proceed at your own risk.

There was a very interesting paper in the USENIX Association's publication,
 ;login: ( "How To Write a Setuid Program", Matt Bishop, ;login:
Vol 12, Number 1, January/February 1987).  An excerpt:
	
    Some versions of UNIX allow command scripts, such as shell scripts,
    to be made setuid ... Unfortunately, given the power and complexity
    of many command interpreters, it is often possible to force them to
    perform actions which were not intended, and which allow the user to
    violate system security.  This leaves the owner of the setuid script
    open to a devastating attack.  In general, such scripts should be avoided.

    ... suppose a site has a setuid script of sh commands.  An attacker
    simply executes the script in such a way that the shell ... appears
    to have been invoked by a person logging in.  UNIX applies the setuid
    bit on the script to the shell, and ... it becomes interactive...

    One way to avoid having a setuid script is to turn off the setuid
    bit on the script, and ... use a setuid [binary] program to invoke it.
    This program should take care to call the command interpreter by its full
    path name, and reset environment information such as file descriptors
    and environment variables to a known state.   However, this method
    should be used only as a last resort and as a temporary measure,
    since with many command interpreters it is possible even under these
    conditions to force them to take undesirable action.

The biggest problem with shell scripts is that you (the programmer /
administrator) have very little control over the programs which run within
the script.  As a very real example, I ran across a script which allowed
users to enter bug reports, using the "vi" editor.  The script was
setuid root, because it wanted to save files in funny places.  The programmer
had guarded against shell escapes (a known feature of vi), by making this
script the login shell.  However, he couldn't guard against another feature
	:e /etc/passwd

You can attempt to make your script as safe as possible by
	1) being very restrictive in your choice of UID.  That is,
	   make the script setuid for a non-privileged user, rather than root
	   (for example, if it must write a log file, could the log file
	   live in some locked area, accessed only by a new and otherwise
	   non-privileged account?)
	2) making the script setgid rather than setuid, with a very
	   restricted GID (see #1)
	3) ensuring that the script is short, very simple, and does not
	   make use of commands such as `vi', `mail' or anything interactive.
	   setuid programs should do ONE thing only, and in a non-complex
	   manner.
	4) setting the PATH, IFS, and other environment variables explicitly
	   within the script
	5) locking down the permissions on the script.  If possible allow it
	   to be run only by group members.  Never allow write permission.
	6) If your version of UNIX permits, take away read permission for
	   anyone other than the owner.  It's a bit harder to break
	   something if you can't see how it works.
	7) Rewrite it in C (carefully)
	8) Convince your management that they don't really need this.

If you plan to keep the script, or re-write it, try and get a copy of the
paper.  If you can't find it, send me mail.
   Vicki Brown   A/UX Development Group		Apple Computer, Inc.
   Internet: vlb@apple.com			MS 58A, 10440 Bubb Rd.	
   UUCP: {sun,amdahl,decwrl}!apple!vlb		Cupertino, CA  95014 USA
              Ooit'n Normaal Mens Ontmoet?  En..., Beviel't?
          (Did you ever meet a normal person?  Did you enjoy it?)