Microsoft Security Bulletin MS02-062

   
Cumulative Patch for Internet Information Service (Q327696)

   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
       
   Technical details
   
     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 Servers Intranet Servers Client Systems
     IIS 4.0 Moderate         Moderate         None
     IIS 5.0 Moderate         Moderate         None
     IIS 5.1 Moderate         Moderate         None
   
     WebDAV Denial of Service:
     
             Internet Servers Intranet Servers Client Systems
     IIS 4.0 None             None             None
     IIS 5.0 Moderate         Moderate         None
     IIS 5.1 Moderate         Moderate         None
   
     Script Source Access Vulnerability:
     
             Internet Servers Intranet Servers Client Systems
     IIS 4.0 None             None             None
     IIS 5.0 Low              Low              None
     IIS 5.1 None             None             None
   
     Cross-site Scripting in IIS Administrative Pages:
     
             Internet Servers Intranet Servers Client Systems
     IIS 4.0 None             None             Low
     IIS 5.0 None             None             Low
     IIS 5.1 None             None             Low
   
     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:
     * Out of Process Privilege Elevation: CAN-2002-0869
     * WebDAV Denial of Service: CAN-2002-1182
     * Script Source Access Vulnerability: CAN-2002-1180
     * Script Source Access Vulnerability: CAN-2002-1181
       
     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.
     
   Frequently asked questions 
   
     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.
     
Patch availability

     Download locations for this patch 
     * IIS 4.0:
       http://www.microsoft.com/Downloads/Release.asp?ReleaseID=43566
     * IIS 5.0:
       http://www.microsoft.com/Downloads/Release.asp?ReleaseID=43296
     * IIS 5.1:
       32-bit:
       http://www.microsoft.com/Downloads/Release.asp?ReleaseID=43578
       64-bit:
       http://www.microsoft.com/Downloads/Release.asp?ReleaseID=43602
       
   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:
     * MS01-028.
     * MS01-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\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
       XP\SP4\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:
          + Microsoft Security Bulletin MS01-043
          + Microsoft Security Bulletin MS01-025
          + Microsoft Security Bulletin MS00-084
          + Microsoft Security Bulletin MS00-018
          + Microsoft Security Bulletin MS00-006
       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.
     * 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.