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.