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 Services can provide assistance with this or any other product support issue.
