Is this a cumulative patch?
No. This patch eliminates a newly discovered security vulnerability,
but it is not cumulative. A cumulative patch for this issue and others
is under development, and will be completed shortly. When it is
available, we will update this bulletin to provide information on how to
obtain it.
Because this patch is not cumulative, we recommend that customers
ensure that they have installed the most recent cumulative patch (delivered
in Microsoft Security Bulletin
MS02-018) before installing this patch.
I thought Microsoft’s policy was to provide cumulative patches for
IIS. Why isn’t this patch cumulative?
Microsoft’s normal policy is to provide security fixes for IIS via
cumulative patches. In fact, a cumulative patch has been underway for
several weeks. However, cumulative patches require extensive testing
because of their scope and wide deployment. As a result, the cumulative
patch is several weeks away from being customer-ready.
The newly discovered vulnerability is similar to another
vulnerability (discussed in Microsoft Security Bulletin
MS02-018), for which exploit tools are already available. At the
same time, eliminating the vulnerability required only a small amount of
code change, in a component with few dependencies on other code. As a
result, we concluded that there was high value in developing a singleton
patch and that we could do so in a much shorter timeframe than usual.
If I don’t want to install the patch, is there a workaround
procedure for this vulnerability?
Yes. As discussed below, the vulnerability can be eliminated by
disabling a rarely used feature in IIS. Customers who have already
disabled this feature don’t need to take any additional action.
What’s the scope of the vulnerability?
This is a buffer overrun vulnerability affecting IIS 4.0 and 5.0. By
sending a specially chosen request to an affected web server, an
attacker could either disrupt web services or gain the ability to run a
program on the server. Such a program would run with full system
privileges in IIS 4.0, and with fewer but nevertheless significant
privileges in IIS 5.0
Microsoft has long recommended that customers remove the
functionality that contains the vulnerability unless there is a
business-critical reason for retaining it, and customers who have done
so would be at no risk from this vulnerability. The
IIS Lockdown Tool disables this functionality by default. Customers
who have retained the functionality but deployed the
URLScan tool as discussed in Microsoft Security Bulletin
MS02-018 would likewise be protected against the vulnerability.
What causes the vulnerability?
The vulnerability results because of an arithmetic error in the ISAPI
extension that implements the HTR functionality. Specifically, the error
lies in a function that enables data to be uploaded to a web server via
chunked encoding, and causes IIS to allocate a buffer of the wrong size
to hold incoming data, with the result that the data could overrun the
end of the buffer.
What is an ISAPI extension?
ISAPI (Internet Services Application Programming Interface) is a
technology that enables web developers to extend the functionality of
their web servers by writing
custom code that provides new services for a web server. Such code
can be implemented in either of two forms:
- As an
ISAPI filter -- a
dynamic link library (.dll) that uses ISAPI to respond to events
that occur on the server.
- As an
ISAPI extension -- a dynamic link library that uses ISAPI to
provide a set of web functions above and beyond those natively
provided by IIS.
In the case of this vulnerability, the affected code is an ISAPI
extension that implements scripting via HTR.
What is HTR?
HTR is a first-generation advanced scripting technology delivered as
part of IIS 2.0. HTR was never widely adopted, largely because a far
superior technology,
Active Server Pages (.ASP), was introduced in IIS 4.0 and became
popular before customers had invested significant development resources
in HTR. However, all versions of IIS through version 5.1 do provide
support for HTR, for purposes of backward compatibility.
Microsoft has long advocated that customers disable HTR on their web
servers, unless there is a business-critical need for the technology. By
default, the
IIS Lockdown Tool disables HTR support, by unmapping the HTR ISAPI
extension.
Are there any widespread uses for HTR?
Virtually the only purpose for which HTR technology is still used
today is web-based password management services. IIS ships with a set of
HTR scripts that, if deployed, make it possible for users to change
their Windows NT passwords via a web server, and make it possible for
administrators to perform password management through the web.
In general, Microsoft recommends against performing password
management over the web. However, for customers who must do this, we
recommend converting any needed HTR scripts to ASP.
What is chunked encoding?
Web servers frequently need the ability to accept data from a user.
For instance, when a visitor to a web site fills in a form and submits
it, the data needs to be uploaded to the server so it can be processed.
In cases like this, the amount of data that will be transferred is known
in advance, and the server can allocate a buffer of the right size.
However, in other scenarios, it’s impossible to know beforehand how much
data will need to be transferred. For instance, an application might be
generating data as it runs, and there might be no way to know exactly
how much data it will produce.
The
HTTP protocol specification provides a way to handle data like this,
through a process called chunked encoding. In chunked encoding, the
client generates a variable-sized quantity of data called a chunk; it
then tells the web server how big the chunk is and sends it. The server
allocates a buffer to accommodate the incoming chunk, then receives and
processes it. As the client generates additional data, it continues
agglomerating it into chunks and delivering them to the server.
What’s wrong with the way the HTR ISAPI extension in IIS 4.0 and
5.0 performs chunked encoding transfers?
There’s an arithmetic error in the IIS 4.0 and 5.0 HTR
implementations, that causes them to miscalculate the size of the buffer
that’s needed for an incoming chunk and allocate one that’s too small.
The result is that the data in the chunk can overlap the end of the
buffer and overwrite other data in system memory, potentially allowing
the operation of IIS to be modified.
How much data could be overwritten?
By design, the client can specify a chunk of any size – if the server
can’t accommodate a chunk that large, it should send an error message to
the client. However, in addition to causing the wrong-sized buffer to be
allocated, the arithmetic error also prevents IIS 4.0 and 5.0 from
placing any real limits on the size of a chunk. As a result, it would be
possible for a client to send a chunk that would overwrite most or all
of the memory in the IIS process
This is a critical point, because it goes to the heart of why this
vulnerability poses a threat to servers. This vulnerability is an
example of so-called heap overrun; because of the dynamic nature of
system memory, these can be more difficult to exploit than stack
overruns and may require more sophisticated skills. Data on the server
can change locations from one moment to the next, impeding the
attacker's ability to overwrite selected programs or data. However, in
this case, the attacker wouldn't need to know where programs were
located, but could instead simply overwrite large portions of system
memory indiscriminately.
What would this enable an attacker to do?
An attacker who exploited this vulnerability could use it for either
of two purposes.
- Service disruption. By overrunning the buffer with random data,
the attacker could corrupt program code and cause the IIS service to
fail, thereby preventing the server from providing useful service.
- Change the operation of the server. By overrunning the buffer with
carefully selected data, the attack could overwrite program code on
the server with new program code, in essence modifying the
functionality of the server software.
Who could exploit the vulnerability?
Any user who was able to establish a web session with an affected
server could exploit the vulnerability.
If the vulnerability were exploited to cause the IIS service to
fail, what would be needed to restore normal operation?
On IIS 4.0, the administrator would need to restart the IIS service.
On IIS 5.0, the service would automatically restart itself.
Why could the vulnerability only be used to cause the IIS service
to fail? If the attacker were able to overwrite system memory
indiscriminately, why not overwrite all memory on the server and cause
the entire operating system to fail?
Windows NT 4.0, Windows 2000 and Windows XP operate in protected
mode. In protected mode, processes can only write to sections of
memory they own. As a result, it would not be possible for the attacker
to overwrite the memory belonging to the operating system.
If the vulnerability were exploited to change the operation of the
server software, what would the attacker be able to do?
In a nutshell, the attacker’s code would gain the privileges of the
software that called it – the HTR ISAPI extension. The privileges that
the attacker could gain would depend on the version of IIS in use on the
server:
- On IIS 4.0, the HTR ISAPI extension runs by default in-process –
that is, as part of the IIS Service, which runs as part of the
operating system itself. As a result, exploiting the vulnerability on
a default IIS 4.0 installation would give the attacker complete
control over the server.
- On IIS 5.0, the HTR ISAPI extension runs by default out-of-process
– that is, in the security context of a special user account called
the Web Application Manager. (Web administrators may know this account
better as IWAM_computername, where computername is the
name of the server). This account has significantly fewer privileges
than the IIS service.
What privileges does the Web Application Manager have?
Essentially, the account has the same privileges as those of an
unprivileged user who was able to log onto the server interactively. It
would not enable an attacker to take administrative action, reconfigure
the server, or access important files such as the Security Account
Manager database.
Nevertheless, it is important not to underestimate the damage that
could be caused using even these privileges. Even these privileges could
be used to cause significant damage. Worse, the vulnerability could
potentially give an attacker a beachhead from which to conduct
additional attacks and try to obtain additional privileges.
I’m running IIS 4.0. Can I configure the HTR ISAPI extension to
run out-of-process?
You
can. However, a better solution is to disable it altogether.
I used the IIS Lockdown Tool to secure my server. Does it disable
the HTR ISAPI extension?
Yes. All versions of the
IIS Lockdown Tool remove the HTR functionality by default, in all
server configurations.
I’ve deployed the URLScan Tool on my server. Will it protect my
system against this vulnerability?
All versions of
URLScan beginning with version 2.5 provide the ability to block
chunked encoding requests. There are two variants of URLScan, known as
“Baseline URLScan” and “URLScan-SRP”. The latter variant blocks chunked
encoding by default. The former can be configured to block chunked
encoding, by adding an entry to the [DenyHeaders] section of URLScan.ini
that reads “Transfer-Encoding:”. (Note: the quotes should not be
included in the entry, but there is a colon at the end of the word “Encoding”).
I’ve disabled the HTR functionality on my IIS server. Do I need
the patch?
If you’ve disabled the HTR functionality, you’re at no risk from this
vulnerability.
How does the patch eliminate this vulnerability?
The patch eliminates the arithmetic error that causes the
vulnerability.
