COMMAND
Internet Information Server
SYSTEMS AFFECTED
Win NT 4.0
PROBLEM
Mnemonix found following. All versions of Internet Information
Server seem to have a feature that can cause security problems
when it has been configured to run Perl scripts to produce dynamic
web pages. Basically the security implications of this problem is
that data can be read from execute only virtual directories
sometimes leading to the discovery of UserIDs and passwords.
Script extentions (in this case .cgi or .pl) are mapped against
the interpreter in the registry under the following key:
HKLM\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\ScriptMap
When the web service receives a request from a browser it checks
the extention of the file requested and deals with it accordingly.
In this case if a .pl or .cgi file is requested IIS checks the
registry to see what interpreter should deal with that kind of
file and then passes the requested information to the interpreter,
perl.exe. Consequently any URL appended with .pl will passed by
IIS to perl.exe. This means that a URL appended with %20.pl will
be passed to perl.exe also.
http://www.site.com/scripts/file.ext%20.pl
To demonstrate how this could be a problem: Some CGI scripts often
require a .txt file that contains a userID and password such as
wwwboard.cgi. Create a text file with two lines. On the first
line type "Webadmin" and on the secondline type "Password". Like
so:
Webadmin
Password
And name the file pass.txt the request the following URL:
http://www.site.com/scripts/pass.txt%20.pl
You should receive a response similar to:
Can't call method "webadmin" in empty package "password" at
C:\InetPub\scripts\pass.txt line 1
You can also glean information from other "sensitive" files such
as .asp or ...idc
http://www.site.com/scripts/default.asp%20.pl
or
http://www.site.com/scripts/database.idc
You could even run old perl scripts that are still in the /scripts
directory but have had their extention changed:
http://www.site.com/scripts/script.pl.old%20.pl
This problem is exacerbated by the fact that perl.exe will accept
willcards such as * and ? so you don't even need to know that name
of a file. You can request:
http://www.site.com/scripts/*.txt%20.pl
and perl.exe will open the first text file in the scripts
directory that it comes across. So what is happening here? The
information passed to perl.exe from the request:
/scripts/file.ext%20.pl is /scripts/file.ext .pl
[note the space]
Perl.exe assumes that the ".pl" is an argument that is to be
passed to the script. So what is actually happening here is IIS
is fooled into thinking that a request has been made for a .pl
file, this information is passed to perl.exe; the file is opened
and passed ".pl" as an argument. Below is a script that will
demonstrate this:
~~~~~~~~~~~~~~~~~~~~~~~arg.pl~~~~~~~~~~~~~~~~~~~~~~~~~~~
$arg=$ARGV[0];
print ("Content type: text/html\n\n");
print ("<HTML><BODY BGCOLOR=#FFFFFF>");
print ("<HR><CENTER><H2>IIS and Perl.exe problem</H2></CENTER><HR>");
print ("Argument passed to perl.exe is $ARGV[0]<HR>");
print "<br>", "PATH_INFO: ", $ENV{'PATH_INFO'};
print "<br>", "PATH_TRANSLATED: ", $ENV{'PATH_TRANSLATED'};
print "<br>", "SCRIPT_NAME: ", $ENV{'SCRIPT_NAME'};
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Request this file with the following URL:
http://your.machine.com/scripts/arg.pl%20.pl
You will see that ".pl" is assgined to the variable $ARGV[0]
This was tested with Perl version 5.001 build 110. It seems that
other versions are affected, too. Affected machines:
NT Server 4.0 Service pack 1 IIS 2.0
NT Server 4.0 Service pack 3 IIS 3.0
NT Server 4.0 Service pack 3 IIS 4.0
NT Wkst 4.0 Service pack 3 PWS 3.0
It is not yet know if other Web servers such as Netscape are
affected. Testing will prove if this is so and would be
appreciated.
SOLUTION
Solution to this problem is to use the ISAPI interpreter instead
PerlIS.dll. This leads to better performance anyway as the script
is run in the same memory space as IIS and only one instance of
it ever needs to be loaded into memory unlike perl.exe where for
each script requested a new instance of perl.exe is loaded into
its own memory space. Although IIS 4.0 can check for the existence
of a file other versions don't and IIS 4.0 has to be specifically
told to do this - it is not done by default. MS should really
create a patch for all versions of IIS that will check for a
file's existence as standard. The EMWAC HTTP Server is not
affected this hole.
SP4 fixed this. 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.