Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!orstcs!sapphire!pvo From: pvo@sapphire.OCE.ORST.EDU (Paul O'Neill) Newsgroups: comp.lang.perl Subject: Re: Trouble with setuid Message-ID: <20044@orstcs.CS.ORST.EDU> Date: 29 Aug 90 06:47:47 GMT References: <^-i2f2.-42@smurf.sub.org> <1990Aug27.181341.425@iwarp.intel.com> Sender: usenet@orstcs.CS.ORST.EDU Reply-To: pvo@sapphire.OCE.ORST.EDU (Paul O'Neill) Organization: Coastal Imaging Lab, Oregon State University, Corvallis, OR Lines: 100 In article <1990Aug27.181341.425@iwarp.intel.com> merlyn@iwarp.intel.com (Randal Schwartz) writes: > >Good for it. It's working properly. Suid scripts are a dangerous >security hole. Don't use'em. If you haven't disabled setuid scripts >on your system, do that. Then, put a little C program wrapper around >your script with the following program > Hmmmm.... Who's the author of this new book? :-) Preferably you disable setuid scripts and use perl setuid emulation. As a second choice, gift-wrap in C. You don't do both. From the man page: Setuid perl scripts are safer than C programs through a dataflow tracing mechanism which prevents many stupid security holes............... In an unpatched 4.2 or 4.3bsd kernel, setuid scripts are intrinsically insecure, but this kernel feature can be dis- abled. If it is, perl can emulate the setuid and setgid mechanism when it notices the otherwise useless setuid/gid bits on perl scripts. [ie-perl AUTOMAGICALLY invokes suidperl on a setuid perl script IF setuid scripts are disabled.] If the kernel feature isn't disabled, perl will complain loudly that your setuid script is insecure. You'll need to either disable the kernel setuid script feature, or put a C wrapper around the script. [OR, you can cheat, and MANUALLY invoke suidperl. Larry says all bets are off on the security of this approach.] Does your system have setreuid()? You *MAY* want to cheat this way. -----------------From a Larry Wall comp.lang.perl posting:--------------- : I found a great use for suidperl. I invoke it directly on my suid perl : script, or start the suid perl script with the line: : #!/usr/local/bin/suidperl : : And the loud complaining about the kernel patch goes away!! : (Now I get to see all the loud complaining about insecure paths, etc., : neat stuff.) Is this a nasty that should be fixed? Possibly. It is certainly the case that if you put a setuid root csh or sh script on your system, and give me a normal account on your system, I could have root privs within about 2 minutes of the time I find the script. : If so, why? Am I asking for trouble doing this w/o the kernel patches? Possibly, especially if you machine doesn't support setreuid(). The problem is that, because of the aliasing possible with links, there is no way to guarantee that the script opened by the interpreter is in fact the same one that the kernel examined and granted setuid privs to. Now suidperl goes to great lengths to assure that the script you are executing is a set-id script, and that the arguments passed on the command line correspond to the #! line, but it can't assure that it is the same script that the kernel execed. If you have setreuid(), suidperl can swap uid and euid and check that it isn't giving away any privs that the kernel wouldn't give away. If you don't, perl can only use access to check the directory permissions, which is known to have race conditions. (Though perl uses fstat to test the file permissions itself.) So suidperl won't let you run a script that's protected against you, and it won't let you run set-id to anything other than what the script itself is set to, but it can let you run a script in a directory that you don't have access to ordinarily, if you don't have setreuid(). A worse problem is if you decide to bypass the loud message by invoking taintperl rather than suidperl. This also bypasses the checks, because taintperl will assume that it is running a wrapped script. In this case, a setuid perl script is as bad as a setuid shell script--basically gives away the farm. A factor contributing to this is that if setuid is really working, and the uid of the script is not root, then the script uid overrides the suidperl uid, and suidperl will note that it is not running as root, and exit. So your trick only works on setuid root programs. This might tempt you on non-root setuid scripts to use taintperl instead, but that's a losing solution, as pointed out in the previous paragraph. : Can I still : consider my "perl script ... more secure than the corresponding C program"? Maybe. If you have setreuid(), it probably is. But I'm not going to guarantee it if you haven't disabled set-id scripts in the kernel. -------------------------END OF L.WALL QUOTE------------------- Paul O'Neill pvo@oce.orst.edu DoD 000006 Coastal Imaging Lab OSU--Oceanography Corvallis, OR 97331 503-737-3251