• Article

Security Bulletin

Microsoft Security Bulletin MS00-086 - Critical

Patch Available for 'Web Server File Request Parsing' Vulnerability

Published: November 06, 2000 | Updated: November 30, 2000

Version: 1.3

Originally posted: November 06, 2000
Updated: November 30, 2000

Summary

On November 06, 2000, Microsoft released the original version of this bulletin, announcing the availability of a patch that eliminates a security vulnerability in Microsoft® Internet Information Services 5.0. The vulnerability could enable a malicious user to run operating system commands on a web server. Since its original issuance, the bulletin has been updated several times:

  • On November 10, 2000, the bulletin was updated to clarify the scope of the issue.
  • On November 21, 2000, it was updated to discuss two newly-discovered variants of the original vulnerability.
  • On November 30, 2000, it was updated to discuss a newly-discovered regression error in the IIS 5.0 patch and recommend that customers apply an updated version of the patch.

The newly-discovered regression error only affects the IIS 5.0 version of the patch. It has no effect on the effectiveness of the patch against the vulnerability discussed here, but it does cause servers to be vulnerable to the "Web Server Directory Traversal" discussed in Microsoft Security Bulletin MS00-078, even if the patch provided in MS00-078 has been applied. Microsoft therefore recommends that all IIS 5.0 customers apply the new patch provided below. It protects against both the "Web Server File Request Parsing" and "Web Server Directory Traversal" vulnerabilities. The IIS 4.0 version of the patch does not contain the error, and customers who have applied the IIS 4.0 patch do not need to take any action.

Affected Software:

  • Microsoft Internet Information Server 4.0
  • Microsoft Internet Information Services 5.0

Vulnerability Identifier: CVE-2000-0886

General Information

Technical details

Technical description:

When IIS receives a valid request for an executable file, it passes the name of the requested file to the underlying operating system for processing. However, due to an implementation flaw, it is possible to create a specially-malformed file request that contains both a file name and one or more operating system commands. Upon receiving such a request, IIS would pass the entire string to the operating system, which would first process the file and then execute the commands.

The ability to execute operating system commands on the web server would enable a malicious user to take virtually any action that an interactively-logged on user could take. Although this would not give the malicious user administrative control over the server, it would nevertheless enable him to cause widespread damage. He could, for instance, add, delete or change files on the server, run code that was already on the server, or upload code of his choice and run it.

There are three significant restrictions on type of file request that could be used to exploit this vulnerability:

  • The malicious user would need to request a .bat or .cmd file.
  • The file would need to exist.
  • The malicious user would need to have execute permissions on the file.

Although these restrictions limit the scope of the vulnerability, it is important not to discount it. Many third-party software products for web servers install batch files by default. As a result, Microsoft recommends that all customers running affected versions of IIS verify whether their systems contain any .bat or .cmd files that can be executed by visitors to the site, and apply the patch immediately if this is the case. The patch for this issue also eliminates the "Web Server Directory Traversal" vulnerability discussed in Microsoft Security Bulletin MS00-078.

Frequently asked questions

What's this bulletin about?
Microsoft Security Bulletin MS00-086 announces the availability of a patch that eliminates a vulnerability in Microsoft® Internet Information Services 4.0 and 5.0. 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.

Why has this bulletin been re-issued?
We've re-issued this bulletin several times, most recently to advise of an error in the IIS 5.0 version of the patch and recommend that all IIS 5.0 customers install an updated version that is now available. The IIS 4.0 version of the patch is not affected by the error, and customers who have applied that patch do not need to take additional action.

What's the error?
We recently learned that, although the IIS 5.0 version of the patch does protect against the vulnerability discussed here, applying it causes the server to be re-exposed to a different, previously-patched vulnerability - even if the patch for that issue was installed. The previous vulnerability is the "Web Server Folder Traversal" vulnerability, and is discussed in Microsoft Security Bulletin MS00-078.

Does the error change the scope of this vulnerability in any way?
No. The scope of the "Web Server File Request" vulnerability is exactly as we have previously described it.

What's the scope of the vulnerability?
This vulnerability would enable a malicious user to execute operating system commands on an affected web server. This would give him the ability to modify web pages, add, change or delete files, reformat the hard drive, or take other actions -- including uploading code of his choice to the server and executing it. The vulnerability could only be exploited if there was at least one .bat or .cmd file that the malicious user had permissions to execute. Even then, it would not grant the malicious user administrative control over the server -- instead, it would grant him privileges normally reserved for a user who could log onto the server interactively. Nevertheless, even these privileges would enable a malicious user to cause widespread damage, and could give him a point from which to launch additional attacks in the hope of gaining additional privileges.

What causes the vulnerability?
The vulnerability results because of a flaw in the way IIS parses file requests. By sending the server a specially-malformed file request, it would be possible for a malicious user to also feed operating system commands to the server, which it would then process in the security context of the anonymous user account for IIS.

When you say the problem involves "the way IIS parses file requests", what do you mean?
By "parsing file requests", we mean the process by which IIS interprets a user's request for a file. Anytime a user requests a file from a web server, one of the tasks the server must perform is to interpret the request and determine what the right action is. The right action often depends on what type of file has been requested. For example, if the user requests a static HTML file, the right action is to simply send the file to the user. Similarly, if the user requests an .ASP file, the right action is to process the file on the server, then send the results to the user. Every type of file has a proper action associated with it.

What type of files are associated with this vulnerability?
The problem has to do with the way IIS handles requests for executable files - scripts, batch files, compiled files, and so forth. When IIS receives a valid request for an executable file, it passes the name of the file to the underlying operating system, which then executes the file. However, there is a flaw in the way IIS handles the requests. It's possible to create a request for an executable file that contains more than just the name of the file - it actually contains the name of a file, followed by operating system commands. Because of the flaw, IIS doesn't reject the request, but instead passes the entire string - file name and operating system commands - to the operating system. This results in the operating system commands being executed on the server.

Are there any restrictions on file that could be used in the request?
Yes. There are three restrictions:

  • The file would need to actually exist on the server. The malicious user couldn't simply make up a file name.
  • The file would need to have either of two extensions, .bat or .cmd
  • The file would need to reside in a folder to which the user has execute permissions.

How common is it for web servers to host batch files and allow visitors to execute them?
In general, best practices recommend against such a practice. However, many third-party products for web servers install batch files by default, with permissions that would enable visitors to execute them. It's therefore very important for administrators running affected products to verify whether their servers host such content.

If a malicious user did exploit the vulnerability, in what security context would the operating system commands be executed?
The operating system commands would be executed in the security context under which the user authenticated to the web site. In the vast majority of cases, this would mean that the commands would be executed under the built-in IUSR_machinename account. This is the account that performs web actions on behalf of anonymous visitors to the site. It's rare for a public web site to allow users to authenticate to user accounts other than IUSR_machinename, but if this were the case, the operating system commands would execute with the privileges of the account to which the user had authenticated. For instance, suppose the webmaster created a user account named Joe, and the malicious user authenticated to the web site as Joe. If he then exploited the vulnerability, the operating system commands would execute in the security context of the Joe account.

What privileges does the IUSR_machinename account have?
The IUSR_machinename account has relatively few privileges under IIS - it only has those that are acceptable for general use by visitors to the site. However, the danger lies in the fact that the vulnerability enables the malicious user to escape from the constraints enforced by IIS, and work directly at the operating system level. In essence, gaining the ability to execute operating system commands in the security context of the IUSR_machinename account would grant the same privileges to the malicious user as those normally available to users who can log onto a machine locally.

Would this vulnerability give a malicious user complete control over the machine?
No. The IUSR_machinename account doesn't have access to many important files and tools. For 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. Likewise, tools like the Local Users and Groups snap-in require administrative privileges to execute. 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.

What would the malicious user be able to do?
In essence, the vulnerability would enable the malicious user to take any action that an interactively-logged on user could take. By default, this would allow him to read and write files, reformat the hard drive, change web pages, and take other actions as well. Worse, it would allow him to upload additional software to the machine and execute it - so, having gained the ability to run code as IUSR_machinename, he could try to leverage this access to gain additional privileges.

Is this vulnerability related to the "Web Server Folder Traversal" vulnerability discussed in Security Bulletin MS00-078?
No. It's easy to conclude that they are related, because they have similar exploit scenarios and effects. However, in reality the two vulnerabilities are unrelated.

If they're unrelated, why does the patch for this issue also eliminate the "Web Server Folder Traversal" vulnerability?
Both issues involve functionality provided by W3SVC.DLL. The patch provided here includes the changes needed to eliminate this vulnerability, as well as the changes that were made earlier to eliminate the "Web Server Folder Traversal" vulnerability. As a result, customers who apply the patch provided here are also protected against the "Web Server Folder Traversal" vulnerability.

Who should use the patch?
Microsoft strongly recommends that all customers using IIS 4.0 or 5.0 apply the patch immediately.

What does the patch do?
The patch eliminates the vulnerability by causing IIS to treat the file request at issue here as invalid.

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 (available soon) 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 Servicescan provide assistance with this or any other product support issue.

Patch availability

Download locations for this patch

Additional information about this patch

Installation platforms: Please see the following references for more information related to this issue.

  • Microsoft Knowledge Base (KB) article Q277873, </https:>https:

Other information:

Acknowledgments

Microsoft thanks  NSFocus (https://www.nsfocus.com) for reporting the original and new variants of this vulnerability to us and working with us to protect customers.

Support: This is a fully supported patch. Information on contacting Microsoft Product Support Services is available at </https:>https:.

Security Resources: The Microsoft TechNet Security Web Site provides additional information about security in Microsoft products.

Disclaimer:

The information provided in the Microsoft Knowledge Base is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.

Revisions:

  • November 06, 2000: Bulletin Created.
  • November 10, 2000: Bulletin updated to indicate that IIS 4.0 is affected when running on pre-SP6 versions of Windows NT 4.0, and to provide information on additional restrictions on the vulnerability.
  • November 21, 2000: Bulletin updated to discuss availability of patch that addresses new variants of vulnerability.
  • November 30, 2000: Bulletin updated to discuss regression error and recommend that customers apply updated patch.

Built at 2014-04-18T13:49:36Z-07:00 </https:>