henry@uunet.uu.net (03/31/89)
>I know of three common modes of attack on set-uid shell scripts, all of >which I have failed to apply successfully to reasonably written shell >scripts under /bin/csh... >The question is, are there any other ways in which shell scripts can be >broken, and which shells do they apply to? The real question is, are you confident that there *aren't* any others? If not, then you cannot consider setuid shell scripts using /bin/csh to be secure. The fundamental security problem with setuid shell scripts is simply that the shells are complex command interpreters which depend on their environment in complicated ways and were not built for security. There's just no way to be sure that the last hole has been found. (If you want another one to check out... Can csh be tricked, by invoking it with suitable arguments, into running the equivalent of a .profile before running the script?) Henry Spencer at U of Toronto Zoology uunet!attcan!utzoo!henry henry@zoo.toronto.edu
guy@uunet.uu.net (Guy Harris) (03/31/89)
> 3: Make a symbolic link to the script from a file called "-s"; > I KNOW OF NO WAY TO CIRCUMVENT THIS WITH /bin/sh > SCRIPTS; #! /bin/sh - The "-" argument will cause the shell to stop scanning its argument list for flag arguments, and treat the argument following it as a script name. However, there's also: 4: <censored> There is another hole in the "#!" mechanism that there is no way to patch merely by properly constructing the script. As far as I know, it can be used to break either shell; the only fix anybody's come up with requires a new kernel facility (basically, the "/dev/fd" mechanism) - thanks and a tip of the Hatlo hat to, as I remember, Dave Korn for coming up with the fix. The presence of that hole is what prompted Berkeley to at least temporarily remove the ability to run shell scripts set-UID (in a posting to "comp.bugs.4bsd" or "comp.bugs.4bsd.ucb-fixes").
mikel@uunet.uu.net (Mikel Lechner) (03/31/89)
will%robots.oxford.ac.uk@nss.cs.ucl.ac.uk (Will Dickson) writes: >> I know of three common modes of attack on set-uid shell scripts, all of >> which I have failed to apply successfully to reasonably written shell >> scripts under /bin/csh, but are successful against scripts with /bin/sh [stuff elided] >> The question is, are there any other ways in which shell scripts can be >> broken, and which shells do they apply to? Yes, there is a very important security hole in set userid shell scripts that has been discussed in other newgroups. The problem is inherent in the way the kernel invokes set userid shell scripts. The set userid shell that is invoked can be spoofed into running a script other than the one that is intended. I was able to verify the bug under SunOS 3.2 and 4.0 with a program I wrote. The fix for this problem is for the shell to insure that the script it is running is actually the one that caused it to be invoked. Neither shell does this check, therefore they are both insecure. Best not to use set userid shell scripts until this problem is fixed. Mikel Lechner UUCP: {decwrl,sun}!teraida!mikel Teradyne EDA Phone: (408) 980-5200 5155 Old Ironsides Drive Santa Clara, Ca 95054
maart@uunet.uu.net (Maarten Litmaath) (04/25/89)
auspex!guy@uunet.uu.net (Guy Harris) writes:
\There is another hole in the "#!" mechanism that there is no way to patch
\merely by properly constructing the script.
My `/bin/setuid' approach does close that hole too; it's provably safe,
thank you. And easy. Email or check comp.sources.misc. BTW, the `hole'
isn't a secret anymore.
Modeless editors and strong typing: |Maarten Litmaath @ VU Amsterdam:
both for people with weak memories. |maart@cs.vu.nl, mcvax!botter!maartigp@uunet.uu.net (Ian Phillipps) (04/26/89)
attcan!utzoo!henry@uunet.uu.net writes: >>I know of three common modes of attack on set-uid shell scripts, all of >>which I have failed to apply successfully to reasonably written shell >>scripts under /bin/csh... >>The question is, are there any other ways in which shell scripts can be >>broken, and which shells do they apply to? >The real question is, are you confident that there *aren't* any others? >(If you want another one to check out... Can csh be tricked, by invoking >it with suitable arguments, into running the equivalent of a .profile >before running the script?) No trickery needed! It's the default! Verified with csh on Sunos 4.0 and a .cshrc file containing "whoami". The script starts with "#!/bin/csh -b" : putting -fb plugs this hole. The -b flag is specifically designed to stop this very problem, and csh will not run suid without it. Having said that, though, my experience of csh is that it has so many quirks that I, for one am not "confident". Larry Wall says that Berkeley 4.? kernels are insecure (reasons left unstated to protect the guilty) for ANY shell script, even perl :-), and has gone to some trouble to circumvent this. Maybe you trust perl less than csh, but at least the author has thought about the problem, and has issued an unanswered challenge for anyone to break perl scripts' security. And you can flame him on the net if it doesn't work :-) UUCP: igp@camcon.co.uk | Cambridge Consultants Ltd | Ian Phillipps or: igp@camcon.uucp | Science Park, Milton Road |----------------- Phone: +44 223 420024 | Cambridge CB4 4DW, England |