gt2500a@prism.gatech.EDU (FLUR) (02/03/90)
I wrote a stupid little script to change my serial port from input
to output by simply having two copies of the ttys file. I then
made the script publicly executable with chmod 4755 from root, but when
I execute the script from my own account, it tells me I don't have
permission. Is this a problem, or am I doing something wrong? The
script follows:
--------------------
Script started on Fri Feb 2 11:17:28 1990
flur@duke> cat /LocalApps/GTNet
v#!/bin/csh
echo -n "Disabling port...."
@ users = `who | grep ttyda | wc -l `
@ kermit = `ps -aux | grep kermit | grep -v grep | wc -l`
@ uucp = `ps -aux | grep uucico | grep -v grep | wc -l`
if ( $users > 0 || $kermit > 0 || $uucp > 0 ) then
echo ""
echo "The port is busy. Please try again later."
exit
else
echo "done."
echo ""
cp /etc/ttys.outgoing /etc/ttys
kill -HUP 1
echo "Using kermit to connect to GTNet."
echo "Type connect <ret> <ret> <ret> to start GTNet."
echo ""
/LocalApps/kermit
echo -n "Enabling port...."
cp /etc/ttys.incoming /etc/ttys
kill -HUP 1
echo "done."
endif
flur@duke> /LocalApps/GTNet
csh: Permission denied
flur@duke> ls -l !$
flur@duke> ls -l /LocalApps/GTNet
-rwsr-xr-x 1 root 618 Jan 31 14:15 /LocalApps/GTNet*
flur@duke>
script done on Fri Feb 2 11:17:53 1990
--------------------
Please --- no flames on the stupid script (except if it is the cause
of the problem)!
Thanks
Peter
----------------------------Peter Flur----------------------------
USMAIL: Box 32500
Georgia Tech, School of Electrical Engineering, Atlanta, GA 30332
USENET: ...!{allegra,hplabs,ihnp4,ulysses}!gatech!duke!flur
INTERNET: flur@duke.gatech.edu, gt2500a@prism.gatech.edu
PHONE: (404) 853-9355carlos@csustan.CSUStan.Edu (02/03/90)
There are two basic things wrong with this shell script, one minor,
the other a serious security problem. First, setuid csh shell
scripts are disabled if not run with the -b option. This
can be incorporated in your shell script by changing the first
line to as follows:
--------------------
#!/bin/csh -b
--------------------
The second problem is much more serious. Without getting into a massive
discussion about the problems of setuid shell scripts, lets just
say that it would behoove you to hard code the path of each command you
wish interpreted by the script such as changing echo to /bin/echo and so
on. It probably would be good also to NOT make this script
publicly accessible by all even after following this advice.
- Advanced Security Technology Corporation -
Carlos Salgado
_/_ ...! uunet Work: +1-704-669-4102
__. _ / _. \
(_/| /_) /_ (__ duke!wolves!secure!carlos
/ Home: +1-704-669-6273
...!usource
carlos@csustan.csustan.edu
--
- Advanced Security Technology Corporation -
Carlos Salgado
_/_ ...! uunet Work: +1-704-669-4102
__. _ / _. \ eps@toaster.SFSU.EDU (Eric P. Scott) (02/03/90)
In article <1990Feb3.015340.20467@csustan.CSUStan.Edu> carlos@csustan.CSUStan.Edu writes: >The second problem is much more serious. Without getting into a massive >discussion about the problems of setuid shell scripts, lets just >say that it would behoove you to hard code the path of each command you >wish interpreted by the script such as changing echo to /bin/echo and so >on. It probably would be good also to NOT make this script >publicly accessible by all even after following this advice. Try #!/bin/csh -fb instead. The f defeats a hole exploited by known security hackers (and also makes your script faster). Back to the original question... what you're doing is inherently the wrong approach anyway. Kermit out on /dev/cua--it's interlocked with /dev/ttyda so you can use the same port for input and output. See the manual page zs(4) for more information. -=EPS=-
jgm@fed.expres.cs.cmu.edu (John G. Myers) (02/03/90)
In article <291@toaster.SFSU.EDU> eps@cs.SFSU.EDU (Eric P. Scott) writes: >In article <1990Feb3.015340.20467@csustan.CSUStan.Edu> > carlos@csustan.CSUStan.Edu writes: >>The second problem is much more serious. Without getting into a massive >>discussion about the problems of setuid shell scripts, lets just >>say that it would behoove you to hard code the path of each command... > >Try #!/bin/csh -fb instead. The f defeats a hole... ...leaving the fact that setuid shell scripts are inherently a security hole, no matter *how* you code them. The existence of a setuid file containing only the single line: #!/bin/csh -fb or even #!/bin/sh - is sufficient to get an interactive shell running as the owner of the file. The problem is inherent in the semantics of shell scripts. Berkeley has published an official fix for BSD which basically disables setuid shell scripts. If you think you want one, write a C program instead. -- _.John G. Myers Internet: jgm@fed.expres.cs.cmu.edu (412) 268-2984 LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
pvo3366@sapphire.OCE.ORST.EDU (Paul O'Neill) (02/04/90)
In article <7818@pt.cs.cmu.edu> jgm@fed.expres.cs.cmu.edu (John G. Myers) writes: > >Berkeley has published an official fix for BSD which basically >disables setuid shell scripts. If you think you want one, write a C >program instead. > More info please. How can we apply this kernel patch to our NeXT's? Paul O'Neill pvo@oce.orst.edu Coastal Imaging Lab OSU--Oceanography Corvallis, OR 97331 503-754-3251
jgm@fed.expres.cs.cmu.edu (John G. Myers) (02/06/90)
In article <15476@orstcs.CS.ORST.EDU> pvo3366@sapphire.OCE.ORST.EDU (Paul O'Neill) writes: >In article <7818@pt.cs.cmu.edu> jgm@fed.expres.cs.cmu.edu (John G. Myers) writes: >>Berkeley has published an official fix for BSD which basically >>disables setuid shell scripts. > >More info please. >How can we apply this kernel patch to our NeXT's? The fix is number 59 and can be gotten via anonymous ftp to uunet.uu.net in the directory "ucb-fixes". I've included it below. Fixing it on NeXT's would require having kernel source. It suffices to simply have no setuid shell scripts on the system. I'd rather not give information on how to exploit the bug. ------------------------------------------------------------ Subject: setuid/setgid shell scripts are a security risk Index: sys/kern_exec.c 4.3BSD Description: Setuid/setgid shell scripts have inherent problems that may be used to violate security. These problems cannot be fixed without completely revising the semantics of executable shell scripts. Fix: Panel your office in asbestos, and apply the following patch to sys/kern_exec.c. *** kern_exec.c.orig Sun May 22 14:07:19 1988 --- kern_exec.c.new Sun May 22 14:07:55 1988 *************** *** 180,185 **** --- 180,187 ---- bcopy((caddr_t)ndp->ni_dent.d_name, (caddr_t)cfname, MAXCOMLEN); cfname[MAXCOMLEN] = '\0'; + uid = u.u_uid; + gid = u.u_gid; goto again; } -- _.John G. Myers Internet: jgm@fed.expres.cs.cmu.edu (412) 268-2984 LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
eps@toaster.SFSU.EDU (Eric P. Scott) (02/06/90)
In article <7846@pt.cs.cmu.edu> jgm@fed.expres.cs.cmu.edu (John G. Myers) writes: >I'd rather not give information on how to exploit the bug. Understandable, given that this is a public forum. HOWEVER--you are not giving the readership enough information to draw reasonable conclusions and arrive arrive at informed decisions. A phrase like "semantics inherent in shell scripts" is hopelessly vague; you never differentiate whether the "interpreter hack" (Using #! as the "magic number" to specify which native executable should be execed with the script as input) is flawed, or whether there's a stupid coding error in the existing shell(s) that is deemed impractical to fix. It really seems that removing a potentially quite useful feature is the wrong approach when perhaps better alternatives exist. As it stands, you're just pandering to fear and ignorance. It's a fair assumption that most comp.sys.next readers don't know beans about UNIX internals, and the popular press has gone hog-wild in the past year or so with "computer crime" stories that mostly breed rampant paranoia. (Yes, I know Berkeley's quality control leaves much to be desired, that's not the point.) In any case, you should send a full report to NeXT, with examples illustrating the problem, and let them worry about how best to handle it. This isn't a popularity contest. In the meantime, simply not using setuid shell scripts seems the simplest and most obvious course of action. True paranoids can use ncheck -s to round up the usual suspects. -=EPS=- -- "It hurts when I do this." "Don't do that."