> I get the distinct impression, based on `perldoc perlsec` that perl > is smart enough to detect and circumvent the relevant > vulnerabilities:
> on many > versions of Unix, set-id scripts are inherently insecure > right from the start. The problem is a race condition in > the kernel. This race condition in the kernel effectively prevents any user space program's ability to work around this. First it depends on the kernel, of course. It happens before perl is run. Therefore if I can trigger the condition I avoid running perl at all. And since the cracker is the one seeing the perl diagnostics in the case that the race condition is going the other way, I in the role of cracker can run in a loop, ingore perl's warnings, keep running until I trigger the race condition the way I want and then stop. Usually I need to load the system down before I can get the race to fall the other way so it takes a while. > However, if the kernel set-id script feature isn't > disabled, Perl will complain loudly that your set-id > script is insecure. I think this means that perl is saying that if your kernel allows this problem to exist that it will prevent a user from thinking that it is a good thing by complaining. Which means that if you are not seeing this message then you are on a system which is okay. Which is true enough. But since I am always porting code I hate running into system specific hacks like that. > No disagreement with respect to s[ug]id shell scripts, though. Agreed. Personally I usually create a C program wrapper to clean the environment and invoke the shell script. But using sudo is probably better. Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
