[21621] in bugtraq
Re: [Khamba Staring ] multiple vulnerabilities in un-cgi
daemon@ATHENA.MIT.EDU (Steven Grimm)
Wed Jul 18 16:25:26 2001
Date: Wed, 18 Jul 2001 12:14:27 -0700
From: Steven Grimm <koreth@midwinter.com>
To: bugtraq@securityfocus.com
Message-ID: <20010718121427.D29434@cadge.midwinter.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ywmbsmigtvj.fsf@nb.mar>; from mar@cf.nettuno.it on Wed, Jul 18, 2001 at 05:05:36PM +0200
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
