Microsoft Security Bulletin MS00-078

Technical description:

Due to a canonicalization error in IIS 4.0 and 5.0, a particular type of malformed URL could be used to access files and folders that lie anywhere on the logical drive that contains the web folders. This would potentially enable a malicious user who visited the web site to gain additional privileges on the machine - specifically, it could be used to gain privileges commensurate with those of a locally logged-on user. Gaining these permissions would enable the malicious user to add, change or delete data, run code already on the server, or upload new code to the server and run it.

The request would be processed under the security context of the IUSR_machinename account, which is the anonymous user account for IIS. Within the web folders, this account has only privileges that are appropriate for untrusted users. However, it is a member of the Everyone and Users groups and, as a result, the ability of the malicious user to access files outside the web folders becomes particularly significant. By default, these groups have execute permissions to most operating system commands, and this would give the malicious user the ability to cause widespread damage. Customers who have proactively removed the Everyone and Users groups from permissions on the server, or who are hosting the web folders on a different drive from the operating system, would be at significantly less risk from the vulnerability.

Microsoft strongly recommends that all customers running IIS 4.0 or 5.0 immediately apply the patch for this vulnerability. This patch was originally released in August 2000 as a fix for a completely different vulnerability (discussed in Microsoft Security Bulletin MS00-057), and customers who have already applied it do not need to take any additional action.

What's this bulletin about?
Microsoft Security Bulletin MS00-078 announces the availability of a patch that eliminates a vulnerability in Microsoft® Internet Information Server. Microsoft is committed to protecting customers' information,and is providing the bulletin to inform customers of the vulnerability and what they can do about it.

What's the scope of the vulnerability?
This vulnerability would enable a malicious user to cause code of his choice to execute on an affected web server. The specific code he could run would be limited by the specific server configuration, but in most cases, it would be possible for the malicious user to execute any code that a user logged into the server interactively could run. This would give him the ability to install and run code, add, change or delete files or web pages, or take other actions. This is a serious vulnerability, and Microsoft recommends that all customers using IIS 4.0 or 5.0 take action immediately to protect their systems.
A patch that was released in August 2000 for a different vulnerability provides complete protection against this vulnerability as well, and customers who have installed it do not need to take any additional action. Also, it is important to understand that the privileges gained via this vulnerability would be those of a locally logged-on user, and not those of the administrator. This means that if an administrator had previously restricted the privileges of non-administrative users on a system, this vulnerability would pose significantly less risk to it.

If there's already a patch available that eliminates the vulnerability, why are you issuing a new bulletin?
We chose to issue this bulletin for two reasons:

• To alert customers to the new vulnerability and the increased risk it poses.
• To urge customers who haven't already applied the patch to do so immediately.

Why didn't you discuss the more-serious vulnerability in MS00-057?
We only recently learned of the new vulnerability. Despite the fact that the "File Permissions Canonicalization" vulnerability and this one share a common solution, they are in fact two completely different vulnerabilities, with different causes and mechanisms.

What causes the vulnerability?
The vulnerability results because it is possible to construct an URL that would cause IIS to navigate to any desired folder on the logical drive that contains the web folder structure, and access files in it.

What do you mean by "navigate to any desired folder"?
Suppose you've installed Windows NT® 4.0 and IIS 4.0 on a machine, and used the default settings. In this case, the system software and web files would be located in various folders on the C: drive. Most of the system files would be located in C:\WINNT\system, and the web folders would be located in D:\inetpub.
One of the principal security functions of a web server is to restrict user requests so they can only access files within the web folders. That is, if the web folders are located in D:\inetpub, it should never be possible for a user to provide an URL that will access a file located outside of D:\inetpub. However, this vulnerability provides a way to do that. Specifically, it provides a way for a malicious user to provide an URL to the web site that will access any file whose name and location he knows, and which is located on the same logical drive as the web folders.

What would this enable the malicious user to do?
It would depend on the permissions associated with the particular file the malicious user requested. If the permissions enabled him to read the file, he could read it. If he had write access to it, he could change it. If it was an executable file and he had permission to run it, he could do so, and it would execute on the server. However, the vulnerability provides no way to circumvent the file permissions.

What executable files are typically available on a web server?
The operating system files themselves would pose the greatest threat. The default permissions would allow the user to execute virtually any operating system command, and these would enable him to cause a wide array of damage. He could, for instance, create new files on the server, delete ones that are already there, or he could reformat the entire hard drive.
However, this isn't the worst he could do. He wouldn't be limited to misusing code that already existed on the server. Access to the operating system commands would give him the ability to upload code of his choice to the machine and execute it.

In what security context would the file access be performed?
The file access would be performed in the security context of the built-in IUSR_machinename account. This is the account that performs web actions on behalf of unauthenticated visitors to the site. Under normal conditions, the account only has permissions to take actions that are acceptable for general use by visitors to the site.
The danger lies in the fact that the vulnerability allows the user to escape from the web folders and access files elsewhere on the drive. By default, many of these files provide access to the Everyone group and/or the Users group, both of which include the IUSR_machinename account as a member. This vulnerability would effectively grant the same privileges to the malicious user as are normally available to users who can log onto a machine locally.

Would this vulnerability give a malicious user complete control over the machine?
No. By itself, the vulnerability only would allow the malicious user to take actions in the context of the IUSR_machinename account, but this account doesn't have access to some important files. To cite just one example, backup copies of the system files in the winnt\repair folder, including the Security Account Manager file (sam._) are only accessible to administrators, and could not be obtained via this vulnerability. Similarly, the default permissions in Windows® 2000 are significantly more restrictive than those in Windows NT 4.0, and the exposure would therefore be less.
However, it is important not to underestimate the damage that a malicious user could cause. Even these privileges would give a malicious user an opportunity to cause significant damage. Worse, the vulnerability could potentially give him a beachhead from which to conduct additional attacks and try to obtain additional privileges. For instance, he could upload malicious code that exploits other known vulnerabilities, and try to exploit them.

Are there any other limitations on the vulnerability?
Yes. The vulnerability only allows files to be accessed if they reside on the same logical drive as the web folders. So, for instance, if a web administrator had configured his server so that the operating system files were installed on the C: drive and the web folders were installed on the D: drive, the malicious user would be unable to use the vulnerability to access the operating system files.
Servers which are configured to host the web folders on their own logical drives would be at least risk from this vulnerability. Even in this case, though, it would be important to ensure that there were no files on the web folders that could be misused, such as sample web applications.

Would an administrator be able to tell if someone had exploited the vulnerability on this server?
Yes. The IIS event log provides information that indicates when someone has tried to exploit the vulnerability. Just search the event log for a successful GET involving an URL that has the string "/../" anywhere in it. Requests like this should, by design, never succeed, so if you see one that did succeed, it means that someone exploited the vulnerability successfully. The next step is to see what the URL maps to. If it maps to a data file, it's likely that the attacker read it. If it maps to an executable file, it's likely that he ran it.

Are there best practices that would reduce the risk posed by vulnerabilities like this one?
Yes. Because of the risk of so-called "directory traversal" vulnerabilities, it's worth taking defensive measures when setting up a web server. These are discussed in the Security Checklists for IIS 4.0 and 5.0, and include:

1. Install your web folders on a drive other than the system drive.
2. Eliminate all sample files and unneeded features from your site.
3. Move, rename or delete any command-line utilities that could assist an attacker, and set restrictive permissions on them.
4. Be sure that the IUSR_machinename account does not have write access to any files on your system.

Who should apply the patch?
Microsoft strongly urges that all customers using IIS 4.0 or IIS 5.0 install the patch immediately. Customers who installed the patch when it was released as part of Microsoft Security Bulletin MS00-057 do not need to take any additional action.

What does the patch do?
The patch eliminates the vulnerability by treating the malformed URL as invalid. This is correct behavior.

Where can I get the patch?
The download location for the patch is provided in the "Patch Availability" section of the security bulletin .

How do I use the patch?
The Knowledge Base article contains detailed instructions for applying the patch to your site.

How can I tell if I installed the patch correctly?
The Knowledge Base article provides a manifest of the files in the patch package.The easiest way to verify that you've installed the patch correctly is to verify that these files are present on your computer, and have the same sizes and creation dates as shown in the KB article.

What is Microsoft doing about this issue?

• Microsoft has delivered a patch that eliminates the vulnerability.
• Microsoft has provided a security bulletin and this FAQ to provide customers with a detailed understanding of the vulnerability and the procedure to eliminate it.
• Microsoft has sent copies of the security bulletin to all subscribers to the Microsoft Product Security Notification Service, a free e-mail service that customers can use to stay up to date with Microsoft security bulletins.
• Microsoft has issued a Knowledge Base article explaining the vulnerability and procedure in more detail.

Where can I learn more about best practices for security?
The Microsoft TechNet Security web site is the best to place to get information about Microsoft security.

How do I get technical support on this issue?
Microsoft Product Support Services can provide assistance with this or any other product support issue.

Download locations for this patch

• Microsoft IIS 4.0:

  http://support.microsoft.com/kb/269862/en-us

• Microsoft IIS 5.0:

  http://technet.microsoft.com/windowsserver/2000/default.aspx

  Note: The IIS 4.0 patch can be installed on systems running Windows NT® 4.0 Service Packs 5 and 6a. It will be included in Windows NT 4.0 Service Pack 7. The IIS 5.0 patch can be installed on systems running either Windows® 2000 Gold or Service Pack 1. It will be included in Windows 2000 Service Pack 2.

  Note: The Download Center pages discussed above may, for the next several days, only reference the "File Permissions Canonicalization" vulnerability. However, we are updating the pages to state that it applies to both that vulnerability and this one.