|
|
|
|
| |
Microsoft has released a patch that eliminates a serious security vulnerability in Microsoft Internet Information Services 5.0. The vulnerability could enable a malicious user to run operating system commands on an affected web server.
Microsoft strongly urges all customers using IIS 5.0 to apply the patch immediately. IIS 4.0 is not affected by the vulnerability. |
| |
Credit:
The information has been provided by Microsoft Product Security.
|
| |
Affected Software Versions:
- Microsoft Internet Information Service 5.0
Note: IIS 4.0 is not affected by the vulnerability.
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 in IIS 5.0, it is possible to create an especially malformed file request that contains both a file name and one or more operating system commands. Upon receiving such a request, IIS 5.0 would pass the entire string to the operating system, which would first process the file and then execute the commands. The file would need to reside in a folder to which the user had execute permissions, but it would not necessarily need to be an executable file.
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.
Microsoft strongly recommends that all customers running IIS 5.0 immediately apply the patch for this vulnerability. The patch also eliminates the Web Server Directory Traversal vulnerability discussed in Microsoft Security Bulletin MS00-078. IIS 4.0 is not affected by the vulnerability, and IIS 4.0 customers do not need to take any action.
Patch Availability:
- English:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25547
- Simplified Chinese:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25580
- Traditional Chinese:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25581
- German:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25582
- Japanese:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25583
Note: This patch can be applied atop system running either Windows 2000 Gold or Service Pack 1. It will be included in Windows 2000 Service Pack 2.
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.
This clearly is a serious vulnerability. 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 5.0 parses file requests. By sending the server an especially 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.
You only mentioned IIS 5.0. Does this vulnerability affect IIS 4.0?
No. Only IIS 5.0 is affected by the vulnerability.
When you say the problem involves "the way IIS 5.0 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 two 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 reside in a folder to which the user has execute permissions.
The latter point is particularly important, because it means that if a web server had no folders that gave execute permission to visitors, the vulnerability couldn't be exploited. However, if there were a single folder that gave execute permissions, it could be exploited.
In what security context would the 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 - they have similar effects, and the patch for this issue also eliminates the vulnerability discussed in MS00-078. 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 5.0 apply the patch immediately.
I'm using IIS 4.0. Do I need to apply the patch?
No. Only IIS 5.0 is affected by the vulnerability.
What does the patch do?
The patch eliminates the vulnerability by causing IIS to treat the file request at issue here as invalid.
How do I use the patch?
Knowledge Base article Q277873 contains detailed instructions for applying the patch to your site.
How can I tell if I installed the patch correctly?
Knowledge Base article Q277873 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.
|
|
|
|
|
|
|
