Export (0) Print
Expand All
This topic has not yet been rated - Rate this topic

Microsoft Security Bulletin MS02-062 - Moderate

Cumulative Patch for Internet Information Service (Q327696)

Published: October 23, 2002 | Updated: November 01, 2002

Version: 1.1

Originally posted: October 30, 2002

Summary

Who should read this bulletin:
Customers hosting web servers using Microsoft® Windows NT® 4.0, Windows® 2000, or Windows XP.

Impact of vulnerability:
Four vulnerabilities, the most serious of which could enable applications on a server to gain system-level privileges.

Maximum Severity Rating:
Moderate

Recommendation:
Customers using IIS 4.0, 5.0 or 5.1 should consider applying the patch

Affected Software:

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

General Information

Technical description:

This patch is a cumulative patch that includes the functionality of all security patches released for IIS 4.0 since Windows NT 4.0 Service Pack 6a, and all security patches released to date for IIS 5.0 and 5.1. A complete listing of the patches superseded by this patch is provided below, in the section titled "Additional information about this patch". Before applying the patch, system administrators should take note of the caveats discussed in the same section.

In addition to including previously released security patches, this patch also includes fixes for the following newly discovered security vulnerabilities affecting IIS 4.0, 5.0 and/or 5.1:

  • A privilege elevation vulnerability affecting the way ISAPIs are launched when an IIS 4.0, 5.0 or 5.1 server is configured to run them out of process. By design, the hosting process (dllhost.exe) should run only in the security context of the IWAM_computername account; however, it can actually be made to acquire LocalSystem privileges under certain circumstances, thereby enabling an ISAPI to do likewise.
  • A denial of service vulnerability that results because of a flaw in the way IIS 5.0 and 5.1 allocate memory for WebDAV requests. If a WebDAV request were malformed in a particular way, IIS would allocate an extremely large amount of memory on the server. By sending several such requests, an attacker could cause the server to fail.
  • A vulnerability involving the operation of the script source access permission in IIS 5.0. This permission operates in addition to the normal read/write permissions for a virtual directory, and regulates whether scripts, .ASP files and executable file types can be uploaded to a write-enabled virtual directory. A typographical error in the table that defines the file types subject to this permission has the effect of omitting .COM files from the list of files subject to the permission. As a result, a user would need only write access to upload such a file.
  • A pair of Cross-Site Scripting (CSS) vulnerabilities affecting IIS 4.0, 5.0 and 5.1, and involving administrative web page. Each of these vulnerabilities have the same scope and effect: an attacker who was able to lure a user into clicking a link on his web site could relay a request containing script to a third-party web site running IIS, thereby causing the third-party site's response (still including the script) to be sent to the user. The script would then render using the security settings of the third-party site rather than the attacker's.

In addition, the patch causes 5.0 and 5.1 to change how frequently the socket backlog list - which, when all connections on a server are allocated, holds the list of pending connection requests - is purged. The patch changes IIS to purge the list more frequently in order to make it more resilient to flooding attacks. The backlog monitoring feature is not present in IIS 4.0.

Mitigating factors:

Out of Process Privilege Elevation:

  • This vulnerability could only be exploited by an attacker who already had the ability to load and execute applications on an affected web server. Normal security practices recommend that untrusted users not be allowed to load applications onto a server, and that even trusted users' applications be scrutinized before allowing them to be loaded.

WebDAV Denial of Service:

  • The vulnerability does not affect IIS 4.0, as WebDAV is not supported in this version of IIS.
  • The vulnerability could only be exploited if the server allowed WebDAV requests to be levied on it. The IIS Lockdown Tool, if deployed in its default configuration, disables such requests.

Script Source Access Vulnerability:

  • The vulnerability could only be exploited if the administrator had granted all users write and execute permissions to one or more virtual directories on the server. Default configurations of IIS would be at no risk from this vulnerability.
  • The vulnerability does not affect IIS 4.0, as WebDAV is not supported in this version of IIS.
  • The vulnerability could only be exploited if the server allowed WebDAV requests to be levied on it. The IIS Lockdown Tool, if deployed in its default configuration, disables such requests.

Cross-site Scripting in IIS Administrative Pages:

  • The vulnerabilities could only be exploited if the attacker could entice another user into visiting a web page and clicking a link on it, or opening an HTML mail.
  • By default, the pages containing the vulnerability are restricted to local IP address. As a result, the vulnerability could only be exploited if the client itself were running IIS.

Severity Rating:

Out of Process Privilege Elevation:

Internet ServersIntranet ServersClient Systems
IIS 4.0 ModerateModerateNone
IIS 5.0 ModerateModerateNone
IIS 5.1 ModerateModerateNone

WebDAV Denial of Service:

Internet ServersIntranet ServersClient Systems
IIS 4.0 NoneNoneNone
IIS 5.0 ModerateModerateNone
IIS 5.1 ModerateModerateNone

Script Source Access Vulnerability:

Internet ServersIntranet ServersClient Systems
IIS 4.0 NoneNoneNone
IIS 5.0 LowLowNone
IIS 5.1 NoneNoneNone

Cross-site Scripting in IIS Administrative Pages:

Internet ServersIntranet ServersClient Systems
IIS 4.0 NoneNoneLow
IIS 5.0 NoneNoneLow
IIS 5.1 NoneNoneLow

The above assessment is based on the types of systems affected by the vulnerability, their typical deployment patterns, and the effect that exploiting the vulnerability would have on them.

Vulnerability identifier:

Tested Versions:

Microsoft tested IIS 4.0, 5.0 and 5.1 to assess whether they are affected by these vulnerabilities. Previous versions are no longer supported, and may or may not be affected by these vulnerabilities.

What vulnerabilities are eliminated by this patch?
This is a cumulative patch that, when applied, eliminates most security vulnerabilities affecting Internet Information Server (IIS) 4.0 (exceptions are listed below in the Caveats section) and all vulnerabilities affecting Internet Information Service 5.0 and 5.1. In addition to eliminating previously discussed vulnerabilities, it also eliminates several new ones:

  • A vulnerability that could enable a rogue application running on a web server to gain control over it.
  • A vulnerability that could enable an attacker to cause a web server to fail.
  • A vulnerability that could enable an attacker to load a program on a web server that already granted permissions that are in most cases inappropriate.
  • A pair of vulnerabilities that could enable an attacker to "bounce" web content to another user's browser session through an IIS 4.0, 5.0 or 5.1 web server.

What products do IIS 4.0, 5.0, and 5.1 ship with?

  • Internet Information Server 4.0 ships as part of the Windows NT 4.0 Option Pack (NTOP).
  • Internet Information Service 5.0 ships as part of Windows 2000 Datacenter Server, Advanced Server, Server and Professional.
  • Internet Information Service 5.1 ships as part of Windows XP Professional. It does not ship as part of Windows XP Home Edition.

Do IIS 4.0, 5.0 and 5.1 run by default?

  • IIS 4.0 runs by default when the NTOP is installed on a Windows NT 4.0 server. It does not run by default when the NTOP is installed on a Windows NT 4.0 workstation, unless Peer Web Services were already running when it was installed.
  • IIS 5.0 runs by default on all Windows 2000 server products. It does not run by default on Windows 2000 Professional.
  • IIS 5.1 does not run by default on Windows XP.

Does the patch include any other fixes?
Yes. In addition to eliminating the security vulnerabilities discussed above, the patch also includes one additional fix correcting a problem that could reduce a server's availability. The issue in this case is not a security vulnerability per se, but is instead a flooding issue in which a huge number of legitimate requests could temporarily swamp a server. (As soon as the flood of requests stopped, the server would return to normal service).
The fix changes how frequently the socket backlog list, which holds pending connection requests when the server has reached its capacity, is purged. In the current design, the list is purged after several seconds, after which point all users' requests compete for positions on the list. If a system had an extremely high bandwidth connection to the server and generated a huge number of connection requests, the relatively infrequent purges could allow it to dominate the backlog list. The fix reduces the purge interval, thereby making it more difficult to do this.

Some of the vulnerabilities apply to certain versions of IIS, but not to others. How do I know whether I need a patch for my version?
If you're running any of the affected products, you should install the patch. The patch will only apply the fixes for the vulnerabilities affecting your version of IIS.

Above and beyond staying up to date on patches, are there any other steps I should take to maintain the security of my web server?
The single most important step you can take to keep your web server secure is to use the IIS Lockdown Tool. The tool will ensure that your server is configured securely and will install the URLScan tool to provide continuing protection while the server is operating.
In addition, there are small number of vulnerabilities affecting IIS 4.0 that cannot be eliminated via software patches. Instead, they require administrative action. All such vulnerabilities are listed below in the Caveats section.

Can these patches be installed on systems running Personal Web Server or Peer Web Services?
In some cases, they can. If you are running either Personal Web Server or Peer Web Services, please consult Microsoft Knowledge Base Article Q307439 for specific information.

Why haven't you discussed IIS 6.0 in the context of these vulnerabilities?
We typically don't discuss beta products in security bulletins. By definition, beta products are incomplete; they're intended for evaluation purposes and shouldn't be used in production systems. However, a small number of customers are engaged in production deployments of IIS 6.0 in conjunction with Microsoft, and we are delivering fixes directly to them.



Out of process privilege elevation vulnerability (CAN-2002-0869):

What's the scope of this vulnerability? 
This is a privilege elevation vulnerability. By exploiting it, an attacker who already had the ability to load and execute applications on a web server could gain system-level privileges, thereby gaining complete control over the system.
The requirement that the attacker be able to load and execute an application on the server could be a fairly daunting one, as best practices strongly recommend against allowing untrusted users to do this. Even trusted users' applications should be scrutinized before allowing them to be uploaded to a web server.

What causes the vulnerability? 
The vulnerability results because, even when IIS is configured to run applications out of process, a rogue application could potentially gain LocalSystem privileges.

What do you mean by running applications "out of process"? 
IIS can be configured to run applications in either of two ways. The applications can be run in-process, in which case they will run as part of the IIS process itself, or out of process, in which case they will run as part of a separate process that's isolated from the IIS process. In IIS 4.0, applications run in-process by default; in IIS 5.0 and 5.1, applications run out of process by default.

What are the advantages of running applications in-process? 
Running applications in-process provides better performance. This is because running in-process allows the applications to share the resources and memory of the IIS process, rather than needing to have their own separately fenced resources.

What are the advantages of running applications out of process? 
Running applications out of process provides two advantages. The first is stability. If an application running in-process fails, it can potentially destabilize IIS itself. In contrast, if an out of process application fails, it could, at most, only destabilize the process it's running within.
The second is security. By design, an application can always gain the privileges of the process it runs within. (For instance, it can do this via the RevertToSelf directive). This means that an application running in-process could gain full administrative privileges on the server, since the IIS process runs in the LocalSystem security context. In contrast, when an application runs out of process, a separate process is created to contain the application, with the credentials of the Web Application Manager account (better known to web administrators as the IWAM_computername account). This account has only the privileges of a normal user, and as a result running out of process significantly limits what a rogue application could do.

What do you mean by a "rogue application"? 
Remember that the scenario here involves applications running on a web server. Clearly, the first line of defense is to use care when determining what applications can run there. Administrators should never allow untrusted users to load and run applications on a server, and even trusted users' applications should be scrutinized before allowing them to be loaded and run on the server. (Microsoft offers a tool called DumpBin for this purpose). The scenario here would only come into play if this safeguard failed, and someone managed to load and run an untrustworthy application on the server.

What's wrong with the way IIS operates when it's configured to run applications out of process? 
By design, it should never be possible for an out of process application to gain any greater privileges than those of the Web Application Manager, because the process in which the application is isolated should have only those privileges. However, through an implementation flaw, the process can be made to actually use LocalSystem privileges, which a rogue application could then assume as well.

What could an attacker do via this vulnerability? 
If an attacker were able to place an application onto the server and execute it, it could be possible for the application to assume the privileges of the local system - that is, the operating system itself. The result would be that the attacker's application would gain full privileges on the server, and be able to take any desired action.

Who could exploit this vulnerability? 
Only an attacker who was able to load and execute code on the server could exploit this vulnerability. The most likely scenarios would be ones in which an attacker had already partially compromised the server and would then use this vulnerability to gain additional privileges, or in which an ISP hosted multiple customers' web sites on a single server and didn't place adequate restrictions on their ability to load and execute code on it.

Why does this vulnerability pose a threat to IIS 4.0 systems, if IIS 4.0 runs applications in-process by default? 
The vulnerability poses no increased risk to IIS 4.0 systems that have been left in the default configuration and run applications in-process. In a nutshell, such configurations of IIS 4.0 are already vulnerable to a rogue application elevating its privileges to LocalSystem.

How does the patch address this vulnerability? 
The patch changes how out of process applications are launched and avoids elevating the privileges of the containing process.



WebDAV denial of service vulnerability (CAN-2002-1182):

What's the scope of this vulnerability? 
This is a denial of service vulnerability. An attacker who successfully exploited it could potentially cause an affected web server to fail, with the subsequent disruption of any web sessions that were in progress at the time. The vulnerability could not be exploited if the IIS Lockdown Tool were deployed in its default configuration. It does not affect IIS 4.0, as that version lacks the feature containing the vulnerability.

What causes the vulnerability? 
The vulnerability results because IIS 5.0 and 5.1 respond to certain types of WebDAV requests by allocating an amount of system memory that far exceeds the appropriate allocation.

What is WebDAV?
WebDAV is an extension to the HTTP specification. The "DAV" in "WebDAV" stands for "distributed authoring and versioning", and it adds a capability for authorized users to remotely add and manage content on a web server. WebDAV is fully supported in Windows 2000 and Windows XP and ships as part of both products.

What's wrong with the way IIS 5.0 and 5.1 handle WebDAV requests? 
When IIS receives a WebDAV request, it typically needs to allocate some memory on the server in which to process the request. However, if the request is malformed in a particular way, a flaw in IIS will cause it to allocate the wrong amount of memory - an amount that's far larger than it should be. Processing only a few such requests could exhaust the system memory and cause the operating system to fail.

What could an attacker do via this vulnerability? 
An attacker who successfully exploited this vulnerability could cause an affected IIS server to fail. All sessions in progress at the time of the attack would be lost, and the administrator would need to reboot the server to restore normal service.

Who could exploit this vulnerability? 
Any user who could deliver a WebDAV request to an affected web server could attempt to exploit the vulnerability. Because WebDAV requests travel over the same port as HTTP (port 80), this in essence means that any user who could establish a connection with an affected server could attempt to exploit the vulnerability.

You said an attacker could "attempt" to exploit the vulnerability. What would determine whether the attempt would succeed? 
In addition to the attacker being able to deliver the request, the server would also need to process it. However, WebDAV can be disabled by using the IIS Lockdown Tool.

Does the vulnerability affect IIS 4.0? 
No. WebDAV isn't supported in IIS 4.0, so the vulnerability doesn't exist there.

How does the patch address the vulnerability? 
The patch causes IIS to treat WebDAV requests of the type described above as invalid and reject them.



Script source access vulnerability (CAN-2002-1180):

What's the scope of this vulnerability? 
This vulnerability could enable an attacker to load a program onto an IIS 5.0 server, if he or she had already been granted other permissions on the server. If the attacker had been granted still other permissions, it might also be possible to run the program.
None of the other needed permissions are granted by default, and it would be extremely difficult for an administrator to grant them by default. The vulnerability does not affect IIS 4.0 or 5.1, and would be blocked if the IIS Lockdown Tool had been deployed in its default settings.

What causes the vulnerability? 
The vulnerability results because of a typographical error in the list of file types that are subject to the script source access permission in IIS 5.0.

What is script source access? 
Script source access is a second layer of defense intended to prevent unauthorized users from loading and running programs on the server. The first layer of defense is write access to the virtual directories on the server. If the administrator hasn't provided users with write access to one or more virtual directories, they cannot load files of any type onto the server.
If the administrator has granted write permissions to a directory, users can upload many types of files. However, they still cannot upload programs, scripts and other executable file types. These files types are subject to an additional permission, called script source access. Unless the administrator has granted both write access and script source access, users should not, by design, be able to upload executable files.

How does IIS know which file types require only write permission, and which require both write and script source access permission?
IIS maintains a list of the file types that require script source access in addition to write access.
What's wrong with the way script source access is implemented in IIS 5.0? There's a typographical error in the list of file types that require script source access. Specifically, the entry for .COM files is misspelled. The result is to exclude .COM files from the restrictions normally associated with executable files, and allow users to upload them with only write access.

What could an attacker do via this vulnerability? 
The vulnerability could potentially enable an attacker to load a .COM file onto a server, even if script source access hasn't been granted. As discussed below, however, there are relatively few scenarios in which a previously secure server would be made vulnerable through this vulnerability.

Who could exploit this vulnerability? 
To exploit the vulnerability, an attacker would need to already have write permission and execute permissions to a virtual directory on the server. By default, IIS does not provide write permissions to any virtual directories.

Why would the attacker need both write and execute permissions? 
Write permissions would be required in order to provide the attacker with a way to upload the .COM file; execute permissions would be required in order to provide him or her with a way to run the file once it was uploaded.

Would the attacker really need execute permissions? Couldn't he or she simply upload the program and then wait for someone else to execute it? 
Permissions on IIS virtual directories aren't allocated on a user-by-user basis, they're allocated globally. That is, in order for anyone to have execute permissions on a virtual directory, everyone must have it.

How likely is it that the administrator could mistakenly grant write or execute permission to a virtual directory? 
Anytime an administrator grants write or execute permissions on a virtual directory, IIS displays a warning message pointing out the dangers associated with doing this, and requires confirmation before proceeding. It's unlikely that an administrator would grant them by accident.

Would the IIS Lockdown Tool help protect the server against this vulnerability? 
Yes. The IIS Lockdown Tool disables WebDAV, without which an attacker would have no way to deliver the .COM file, even on an otherwise vulnerable server.

Are either IIS 4.0 or 5.1 affected by the vulnerability? 
No. Only IIS 5.0 is affected by it.

How does the patch address the vulnerability? 
The patch corrects the typographical error, thereby subjecting .COM files to the script source access restrictions.



Cross-Site Scripting Vulnerablity in IIS Administrative Pages (CAN-2002-1181):

What's the scope of these vulnerabilities? 
These are all cross-site scripting vulnerabilities. The scope and effect of all of them is the same -- through these vulnerabilities, it could be possible for an attacker to send a request to an affected server that would cause a web page containing script to be sent to another user. The script would execute within the user's browser as though it had come from the third-party site. This would let it run using the security settings appropriate to the third-part web site, as well as allowing the attacker to access any data belonging to the site.
The vulnerability could only be exploited if the user's system were also configured to act as a web server. Even then, it could only be exploited if the user opened an HTML mail or visited a malicious user's web site - the code could not be "injected" into an existing session.

What causes the vulnerability?
Certain web services provided by IIS don't properly validate all inputs before using them, and are consequently vulnerable to Cross-Site Scripting (CSS).

What's Cross-Site Scripting?
CSS is a security vulnerability that potentially enables a malicious user to "inject" code into a user's session with a web site. Unlike most security vulnerabilities, CSS doesn't apply to any single vendor's products - instead, it can affect any software that runs on a web server and doesn't follow defensive programming practices. In early 2000, Microsoft and CERT worked together to inform the software industry of the issue and lead an industry-wide response to it.

How does CSS work?
A good description is available in the form of an executive summary and a FAQ. However, at a high level of detail, here's how CSS works. Suppose Web Site A offers a search feature that lets a user type a word or phrase to search for. If the user typed "banana" in as the search phrase, the site would search for the phrase, then generate a web page saying "I'm sorry, but I can't find the word 'banana'". It would send the web page to his browser, which would then parse the page and display it.
Now suppose that, instead of entering "banana" as the search phrase, the user entered something like "banana ‹SCRIPT› ‹Alert('Hello');› ‹/SCRIPT›". If the search feature were written to blindly use whatever search phrase it's provided, it would search for the entire string, and create a web page saying "I'm sorry, but I can't find the word "banana ‹SCRIPT› ‹Alert('Hello');› ‹/SCRIPT›"". However, all of the text beginning with "‹SCRIPT›" and ending with "‹/SCRIPT›" is actually program code, so when the page was processed, a dialogue box would be displayed by the user's browser, saying "Hello".
So far, this example has only shown how a user could "relay" code off a web server and make it run on his own machine. That's not a security vulnerability. However, it's possible for a malicious web site operator to invoke this vulnerability to run on the computer of a user who visits his site. If Web Site B were operated by a malicious user who was able to entice the user into visiting it and clicking a hyperlink, Web Site B could go to Web Site A, fill in the search page with malicious script, and submit it on behalf of the user. The resulting page would return to the user (since the user, having clicked on the hyperlink, was ultimately the requester), and process on the user's machine.

What could the script do on the user's machine?
The script from Web Site B (the attacker's site) would run on the user's machine as though it had come from Web Site A. In practical terms, this would mean two things:

  • It would run using the security settings on the user's machine that were appropriate to Web Site A.
  • The script from Web Site B would be able to access cookies and any other data on the user's system that belonged to Web Site A.

Would it matter what browser the user was using?
No. The important point here is that the problem lies with the software on the web server, not with the browser. The vulnerability could potentially occur anytime software on the web server blindly uses whatever inputs it's provided. Instead, it should filter out any inputs that aren't appropriate. In the example above, the search engine should strip out any characters that could be used to inject script into the search process, such as "". A full description of the characters that should be filtered is available in Knowledge Base article Q252985.

What's wrong with IIS?
Several web pages provided by IIS for administrative or documentation purposes don't properly filter their inputs, and as a result could be used in a cross-site scripting attack.

What would these vulnerabilities enable an attacker to do?
The vulnerabilities would allow an attacker who operated a web site and was able to lure another user into clicking a link on it to carry out a cross-site scripting attack via another web site that was running IIS. As discussed above, this would enable the attacker to run script in the user's browser using the security settings of the other web site (the one running IIS), and to access cookies and other data belonging to it.
It's important to note, though, an important mitigating factor. The web pages containing the vulnerability can, by default, only be accessed if they're located on the user's own machine. The practical effect of this would be to make the vulnerability exploitable only if the user's machine were already serving as a web server.

Does this vulnerability provide any way for the attacker to harm my web site?
No. The attacker couldn't take any action against your site, but would be able to use your site as an unwitting accomplice in an attack against people who may visit your site.

You said that the point of the attack would be for the attacker to get script running in the user's browser using the security settings of my web site. What specific capabilities would the attacker gain by doing this?
It would vary from site to site, based on what Security Zone the attacker's site and yours were placed in.

  • If they were both in the same zone (and by default, all web sites reside in the Internet Zone unless the user moves them), they would both be subject to exactly the same security restrictions and the attacker would gain nothing through the vulnerability.
  • If the user had put the attacker's site into a more restricted zone than yours, the attacker would gain the ability for his script to do anything on the user's computer that script from your site could do.
  • If the user had put your site into a more restricted zone than yours, the attacker would actually lose capabilities through the attack.

It's important to note, however, that regardless of the security settings, the attacker's script would always be able to access cookies and any other data on the user's system belonging to the third-party site. This is because, as far as the browser can tell, the attacker is the third-party site.

How does the patch address the vulnerability?
The patch eliminates the vulnerability by ensuring that the web pages discussed above properly filter their inputs before using them.

Download locations for this patch

Additional information about this patch

Installation platforms:

  • The IIS 4.0 patch can be installed on systems running Windows NT 4.0 Service Pack 6a.
  • The IIS 5.0 patch can be installed on systems running Windows 2000 Service Pack 2 or Service Pack 3.
  • The IIS 5.1 patch can be installed on systems running Windows XP Professional Gold and Service Pack 1.

Inclusion in future service packs:

  • No additional service packs are planned for Windows NT 4.0.
  • The IIS 5.0 fixes will be included in Windows 2000 Service Pack 4.
  • The IIS 5.1 fixes will be included in Windows XP Service Pack 2.

Reboot needed:

  • IIS 4.0: A reboot can be avoid by stopping the IIS service, installing the patch with the /z switch, then restarting the service. Knowledge Base article Q327696 provides additional information on this procedure.
  • IIS 5.0: In most cases, the patch does not require a reboot. The installer stops the needed services, applies the patch, then restarts them. However, if the needed services cannot be stopped for any reason, it will require a reboot. If this occurs, a prompt will be displayed advising of the need to reboot.
  • IIS 5.1: No. (In some cases, a pop-up dialogue may say that the system needs to be rebooted in order for the patch installation process to be completed. This dialogue, if it appears, can be ignored)

Patch can be uninstalled: Yes

Superseded patches:

This patch supersedes the ones provided in the following Microsoft Security Bulletins:

  • MS02-028.
  • MS02-018. (This is a cumulative patch, and supersedes additional patches)

Verifying patch installation:

IIS 4.0:

  • To verify that the patch has been installed on the machine, confirm that the following registry key has been created on the machine:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\Q327696.

  • To verify the individual files, consult the file manifest in Knowledge Base article Q327696.

IIS 5.0:

  • To verify that the patch has been installed on the machine, confirm that the following registry key has been created on the machine:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows 2000\SP4\Q327696.

  • To verify the individual files, use the date/time and version information provided in the following registry key:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows 2000\SP4\Q327696\Filelist.

IIS 5.1:

  • To verify that the patch has been installed on the machine, confirm that the following registry key has been created on the machine:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows XP\SP2\Q327696.

  • To verify the individual files, use the date/time and version information provided in the following registry key:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows XP\SP2\Q327696\Filelist.

Caveats:

  1. The fixes for four vulnerabilities affecting IIS 4.0 servers are not included in the patch, because they require administrative action rather than a software change. Administrators should ensure that in addition to applying this patch, they also have taken the administrative action discussed in the following bulletins:
    • Microsoft Security Bulletin MS00-028
    • Microsoft Security Bulletin MS00-025
    • Microsoft Security Bulletin MS99-025 (which discusses the same issue as Microsoft Security Bulletin MS98-004)
    • Microsoft Security Bulletin MS99-013
  2. The patch does not include fixes for vulnerabilities involving non-IIS products like Front Page Server Extensions and Index Server, even though these products are closely associated with IIS and typically installed on IIS servers. At this writing, the bulletins discussing these vulnerabilities are:

    There is, however, one exception. The fix for the vulnerability affecting Index Server which is discussed in Microsoft Security Bulletin MS01-033 is included in this patch. We have included it because of the seriousness of the issue for IIS servers.

  3. Customers using IIS 4.0 should ensure that they have followed the correct installation order before installing this or any security patch. Specifically, customers should ensure that Windows NT 4.0 Service Pack 6a has been applied (or re-applied) after installing the IIS 4.0 service.
  4. Customers using Site Server should be aware that a previously documented issue involving intermittent authentication errors has been determined to affect this and a small number of other patches. Microsoft Knowledge Base article Q317815 discusses the issue and how resolve it.

Localization:

Localized versions of this patch are available at the locations discussed in "Patch Availability".

Obtaining other security patches:

Patches for other security issues are available from the following locations:

  • Security patches are available from the Microsoft Download Center, and can be most easily found by doing a keyword search for "security_patch".
  • Patches for consumer platforms are available from the WindowsUpdate web site

Other information:

Acknowledgments

Microsoft thanks the following people for reporting this issue to us and working with us to protect customers:

  • Li0n of A3 Security Consulting Co., Ltd. (http://www.a3sc.co.kr) for reporting the Out of process privilege elevation vulnerability.
  • Mark Litchfield of Next Generation Security Software Ltd. (http://www.nextgenss.com) for reporting the WebDAV denial of service vulnerability.
  • Tomoki Sanaki of International Network Security, Inc., for reporting the script source access vulnerability.
  • Arai Yuu of LAC (http://www.lac.co.jp/) for reporting the cross-site scripting vulnerability in IIS administrative pages.
  • Luciano Martins of Deloitte & Touche Argentina (http://www.deloitte.com.ar) for recommending the change in the socket backlog list purge rate.

Support:

  • Microsoft Knowledge Base article Q327696 discusses this issue and will be available approximately 24 hours after the release of this bulletin. Knowledge Base articles can be found on the Microsoft Online Support web site.
  • Technical support is available from Microsoft Product Support Services. There is no charge for support calls associated with security patches.

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:

  • V1.0 (October 23, 2002): Bulletin Created.
  • V1.1 (November 01, 2002): Bulletin updated to update Acknowledgments section.

Built at 2014-04-18T13:49:36Z-07:00

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.