(Vendor Releases Fix) Re: Sambar Server's Web Server Lets Local Users Disclose Files Outside of the Documents Directory
SecurityTracker Alert ID: 1002041|
SecurityTracker URL: http://securitytracker.com/id/1002041
(Links to External Site)
Date: Jul 18 2001
Disclosure of system information, Disclosure of user information|
Fix Available: Yes Vendor Confirmed: Yes |
Version(s): prior to 5.0 Beta 6|
The vendor reports that there are several vulnerabilities in the Sambar Server WWW server. One vulnerability allows local users (or remote users with .shtml upload privileges) to disclose the contents of files on the system to remote users. The nature of the other vulnerability was not disclosed.|
The vendor indicates that the web server contains a Server Side Includes (SSI) bug that allows local users to specify the "#include file" functionality to display the contents of files outside the Documents Directory. To trigger this vulnerability, the user must be a local user or must have privileges to upload .shtml files to the server. The local user can insert "../" characters in the #include file directive to cause it to break out of the Documents Directory.
All versions of the Sambar WWW Server prior to 5.0 beta 5 have a second security vulnerability in the pagecount sample code. The nature of this vulnerability was not disclosed.
[Editor's Note: The following older vulnerabilities are described below for completeness but are not formally part of this alert.]
The 4.2 and 4.3 production releases reportedly contain a vulnerability in the netutils sample code. A buffer-overrun exploit can reportedly be used against the "finger" RPC.
The 4.3 production release reportedly contains a vulnerability that can allow a remote user to access .htm and .html files in a directory secured by .htaccess constraints. To trigger this vulnerability, the remote user must know the file name in the secured directory.
A local user can cause files outside of the Documents Directory to be disclosed to remote web users.|
The vendor has released a fix for the "../" directory traversal vulnerability.|
Vendor URL: www.sambar.com/ (Links to External Site)
Access control error, Input validation error|
Windows (Me), Windows (NT), Windows (95), Windows (98), Windows (2000)|
This archive entry is a follow-up to the message listed below.|
Source Message Contents
Date: Wed, 18 Jul 2001 12:14:27 -0700|
Subject: Re: [Khamba Staring <email@example.com>] multiple vulnerabilities in un-cgi
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:
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.