Xref: utzoo comp.unix.internals:2325 comp.unix.admin:1195 Path: utzoo!news-server.csri.toronto.edu!rutgers!dimacs.rutgers.edu!seismo!uunet!convex!usenet From: tchrist@convex.COM (Tom Christiansen) Newsgroups: comp.unix.internals,comp.unix.admin Subject: Re: Unix security additions Message-ID: <1991Mar13.184136.19995@convex.com> Date: 13 Mar 91 18:41:36 GMT References: <39950@cup.portal.com> <565@rufus.UUCP> <1921@bacchus.esa.oz.au> Sender: usenet@convex.com (news access account) Reply-To: tchrist@convex.COM (Tom Christiansen) Organization: CONVEX Software Development, Richardson, TX Lines: 135 Nntp-Posting-Host: pixel.convex.com From the keyboard of craig@bacchus.esa.oz.au (Craig Macbride): :>o Eliminating setuid shell scripts : :A good idea in theory, but the security of the system is still largely a :matter of how it's administered. Why shouldn't people who want to use setuid :shell scripts be allowed to? Because IBM or AT&T says so? Do you think they say for just for the sake of pervicacity? There are two very good reasons for not running suid scripts. The first is that there is a well-known and almost never-fixed race condition in the kernel by which the mere presence of a setuid root script on your system will allow anyone to become root who can make a link to that file. This has been known for many years, but almost no vendor fixes it. At most, if you're very lucky, they disable it. You should complain bitterly to your vendor if they've done neither, as they are being negligent. Most are. You might like to know that Maarten Litmaath's indir program can be used to circumvent this bug. The second reason for never using setuid shell scripts is that the amount of effort you have to go through to guarantee their security even once the aforementioned bug is fixed is truly exhaustive. Merely wrapping the shell script with a setuid C wrapper does nothing to deal with all these problems. I have appended a posting detailing these. Two more quick points before that, though. First, the perl language had as one of its design goals the ability to write secure programs in it. A suid program written in perl is often safer than a C program, because the run-time system catches brain-dead errors that neither shell scripts nor C programs check for. Check out the section on "Setuid Scripts" in the perl man page or the perl book for details. The other thing is that often I have a brief program that I believe gives you the ability to grant someone edit rights on a file from a suid program without giving away the whole farm. It does this by putting the file in a chrooted directory while it's being edited. I'll be happy to mail this out to anyone who asks, or to post it if there's sufficient interest. --tom ------- Forwarded Message Date: 10 Aug 90 19:41:32 GMT From: vlb@magic.apple.com (Vicki Brown) Subject: Re: Suid script security Organization: Apple Computer Newsgroups: comp.unix.questions 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?) ------- End of Forwarded Message