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