COMMAND
IIS
SYSTEMS AFFECTED
WinNT with IIS
PROBLEM
'3APA3A' found following. 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.
For example, if perl configured as an external CGI program for .pl
files and user requests nonexistent .pl file
http://www.somehost.com/nonexistant.pl
IIS calls perl with nonexistant.pl, and generates error message:
"<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
"d:\inetpub\wwwroot\present\security\nonexistant.pl":
No such file or directory
</pre>"
SOLUTION
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. 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.