[14125] in bugtraq
Re: IIS dosn't check existance of local file before calling CGI
daemon@ATHENA.MIT.EDU (Bronek Kozicki)
Wed Mar 1 20:44:35 2000
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <000401bf8370$e2881c50$fac9a8c0@poland.wpi>
Date: Wed, 1 Mar 2000 12:25:44 +0100
Reply-To: Bronek Kozicki <bronek@WPI.COM.PL>
From: Bronek Kozicki <bronek@WPI.COM.PL>
X-To: BugTraq Mailing List <BUGTRAQ@SECURITYFOCUS.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <12925.000229@SECURITY.NNOV.RU>
From: Bugtraq List [mailto:BUGTRAQ@SECURITYFOCUS.COM]On Behalf Of 3APA3A
> Sent: wtorek, 29 lutego 2000 20:12
> To: BUGTRAQ@SECURITYFOCUS.COM
> Subject: IIS dosn't check existance of local file before calling CGI
>
>
> Hello,
>
> There is another one way to retrieve a full path to local files in
> IIS4:
>
> If there is external CGI application configured for some file type
> and this application doesn't produce correct HTTP headers IIS
> generates an error with output of application (both stdout and
> stderror). The problem is, that IIS doesn't check existance of the
> requested file before calling CGI application.
Hello
you can set IIS to verify that requested file (CGI script) exits, before it
calls external application. It's recommended that you always set this option
on (AFAIR it's set by ActivePerl setup for .pl files) , however Microsoft
own ISAPI applications do not have it set by default - administrator has to
do it himself . IMHO nothing bad about it - anyway he/she must take some
actions to fortify IIS4, as its default installation is not even supposed to
be secure. All necessary steps are well described in MS whitepaper (but I do
not remember what it says about his particular option :-/ ).
Here goes example:
1) option "check that file exists" is NOT set, called external CGI (not
ISAPI) application (behavior described by 3APA3A )
<head><title>Error in CGI Application</title></head>
<body><h1>CGI Error</h1>The specified CGI application misbehaved by not
returning a complete set of HTTP headers. The headers it did return
are:<p><p><pre>Can't open perl script
"C:\InetPub\wwwroot\cgi-bin\nosuchfile.pl": No such file or directory
</pre>
2) option "check that file exists" IS set , called external CGI (not ISAPI)
application:
<html><head><title>Error 404</title>
<meta name="robots" content="noindex">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html;
charset=iso-8859-1"></head>
<body>
<h2>HTTP Error 404</h2>
<p><strong>404 Not Found</strong></p>
<p>The Web server cannot find the file or script you asked for. Please check
the URL to ensure that the path is correct.</p>
<p>Please contact the server's administrator if this problem persists.</p>
</body></html>
If application called is a "script engine" (ISAPI application - as ASP and
SSI is) AND option "check that file exists" is NOT set, you will receive
response specific to this particular ISAPI application (usually error 404,
eventually some kind of invalid response). Probably this is why MS does not
set this option for own ISAPI applications - these are supposed to return
error 404 on their own. Well, it reminds me well known buffer overflow in
ism.dll - which could not be exploited if IIS verifies that requested .htr
file exists, before calling ISAPI.
I believe that what 3APA3A descriped is rather result of poor administration
practices, not error in IIS implementation
Regards
B. Kozicki
