Software Engineering Institute

IIS 4 and 5 provide the ability for web administrators to place executable files and scripts on the web server for execution on the server by visitors to the site. The executability and scriptability of files on the server can be controlled on a directory-by-directory basis. Additionally, by design, IIS restricts access to files on the server to only those files in the web folder(s). This includes attempts to access files through a relative reference such as

http://www.example.org/data/../../../winnt/file.dat

By design, attempts to access a file in this manner will fail.

Furthermore, an attempt to execute a file contained in a directory not marked as executable will fail. For example,

http://www.example.org/data/prog.exe

will attempt to download the file prog.exe to the web browser rather than executing it on the server. However, an administrator can permit the execution of files on the server by marking their parent directory as executable. IIS includes a set of default directories in the web folder; including a scripts directory, which is executable by default. Therefore, by default, a reference to

http://www.example.org/scripts/prog.exe

will cause IIS to attempt to execute prog.exe. For the same reason that an attempt to read file.dat through a relative reference will fail as shown above, an attempt to execute prog2.exe via a relative reference will fail as well. That is, a reference to

http://www.example.org/data/../../../winnt/prog2.exe

will neither download prog2.exe nor attempt to execute it. However, if an intruder encodes the relative reference to prog2.exe using certain unicode characters, IIS fails to prevent access to it. If the relative reference is relative to a directory marked as executable, the reference will result in an attempt to execute the file. For example, by default, a reference to

http://www.example.org/scripts/../../../winnt/prog2.exe

will cause IIS to attempt to execute prog2.exe if the reference is encoded using certain unicode characters (not shown above). Other references can be constructed to simply attempt to read files; such references do not need to be relative to a directory marked as executable.

Whether or not an attempt to read or execute a file will succeed depends on the access permissions IIS has with respect to that file. For the purposes of reading and executing files, IIS runs with the permissions of the IUSR_machinename account. NTFS can be used to reduce susceptibility to this vulnerability by setting permissions such that the IUSR_machinename account cannot access files outside the web folder. IIS servers using the FAT file system are unable to use file system permissions to mitigate against this vulnerability.

Remote users can execute arbitrary commands with the privileges of the IUSR_machinename account.

Apply the patch described in MS01-044. This patch is a cumulative patch that covers a variety of security problems discovered prior to August 15, 2001. Alternately, you can install a patch from Microsoft as described in MS00-078, though that addresses only this specific vulnerability. The patch was first announced in MS00-057.

As a general practice, and to mitigate against this vulnerability if you are unable to install a patch, use NTFS file permissions to restrict IIS so that it can only access files contained in the web server. Additionally, because relative references to files cannot cross volume boundaries, you may wish to configure IIS such that the web folder is on a separate volume. That is, keep the web data on the D: drive and everything else on the C: drive. However, note that this provides only very limited protection and can be circumvented by an intruder.