Bugtraq mailing list archives
Re: [Khamba Staring <purrcat () edoropolis org>] multiple vulnerabilities in un-cgi
From: Steven Grimm <koreth () midwinter com>
Date: Wed, 18 Jul 2001 12:14:27 -0700
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
Current thread:
- Re: [Khamba Staring <purrcat () edoropolis org>] multiple vulnerabilities in un-cgi Steven Grimm (Jul 18)
- Re[2]: long filename issue in Win9x Phaedrus (Jul 19)