Un-CGI's author here, with a response to this report. > 1. uncgi does no relative directory checking; this means anyone can > execute any program on the remote system as the http user (to some > extent, permission wise of course) using the simple dot-dot-slash trick. I've released a fix for the ../ hole; thanks for pointing that one out. http://www.midwinter.com/~koreth/uncgi.html has a link to the new version. Adding relative directory checking beyond that would have little security benefit. The following two-line shell script demonstrates why: #!/bin/sh /run/a/malicious/program/somewhere/else Put that script in Un-CGI's script directory and you're off and running. If you can put a symbolic link into the script directory, you can put a script like this there instead, so blocking symbolic links doesn't make your system particularly more secure. > 2. uncgi does not check if the script it will execute has any executable > bits turned on. As most CGI scripts are just that-- scripts, uncgi > will try to execute the program located behind #! on the first line > of the CGI script and feed the CGI script filename itself as an > argument. This means the CGI script doesn't have to be executable > for uncgi to be able to execute it. See above. Nothing prevents a malicious user with write access to the script directory from writing an executable script that runs a non- executable one. Running scripts that don't have execute permission set is a convenience feature and frankly in the 7+ years Un-CGI has been released this is the first I can remember anyone taking issue with it. However, I've added a compile-time switch to disable the feature for those who feel it's not worth the potential for abuse. With the exception of the ../ hole, Un-CGI's security is exactly the same as the security of your script directory. Which, really, when you think about it, is also true of a typical CGI-capable Web server; as soon as you let random users stick programs in the cgi-bin directory you're opening yourself up to potential security problems. > As these vulnerabilities are > so easy to exploit, I almost know for sure these vulnerabilities are > already being exploited. Almost? I have a hard time imagining any that would have been prevented (as opposed to delayed for a few seconds) by adding realpath() calls and checking for executable bits. If you know of any specific instances of exploits, please drop me a line so I can talk to the sysadmins in question and get more details. Even the ../ hole is only theoretical on many Web servers; on my system, for example, the server silently translates /cgi-bin/uncgi/foo/../bar to /cgi-bin/uncgi/bar before running Un-CGI. But in any case it should no longer be a problem even on servers that don't do internal .. detection. -Steve
This archive was generated by hypermail 2b30 : Wed Jul 18 2001 - 13:24:08 PDT