COMMAND

    Perl.exe

SYSTEMS AFFECTED

    Systems with IIS and perl

PROBLEM

    mnemonix  found  following.   There  is  a  problem  with perl.exe
    similar to  the issue  discussed in  KB article  Q193689 where the
    physical  disk  location  of  a  virtual  web  directory  can   be
    ascertained.  In all  versions of IIS, where  a  website has  been
    configured to  interpret perl  scripts using  the perl  executable
    (perl.exe), a problem  exists where a  request for a  non-existent
    file  will  return  the  physical  location  on  a  disk  of a web
    directory.  A request for:

        http://www.server.com/scripts/no-such-file.pl

    will return information similar to the following:

        CGI Error
        The specified CGI application misbehaved by not returning a complete set of
        HTTP headers. The headers it did return are:
        Can't open perl script "C:\InetPub\scripts\no-such-file.pl": No such file or
        directory

    Previously this was a problem when requesting a non-existent  .IDC
    file but this was resolved with Service Pack 4.

SOLUTION

    To resolve this problem in IIS 2 and 3 you can use perlis.dll, the
    ISAPI version of the perl interpreter,  instead of the executable.
    You can use this in IIS 4  as well, however, if you still want  to
    use  perl.exe  you  can  configure  IIS  to  check  for the file's
    existence.  NTInfoScan, downloadable from

        http://www.infowar.co.uk/mnemonix/ntinfoscan.htm

    checks  for  this  problem  and  the  .IDC  issue as well as other
    security checks.  Note that if you install SP5 without  previously
    SP4  and  SP5  is  supposed  to  resolve  all  issues addressed by
    previous service packs, after  running David Litchfield's NT  Info
    Scanner on the machine in  question, you'll find that the  path to
    the  IIS  root  directory  can  still  be obtained by requesting a
    nonexistent .idc file.  As described in Microsoft article  Q193689
    this issue  is fixed  by SP4.   However, SP5  apparently does  not
    repair it.   Perhaps this is  the intended behavior,  but it seems
    like a bug.