荔园在线
荔园之美，在春之萌芽，在夏之绽放，在秋之收获，在冬之沉淀
[回到开始]
[上一篇][下一篇]
发信人: seawolf (眞·海狼seawolf), 信区: Security
标 题: Microsoft Security Bulletin MS02-018
发信站: 荔园晨风BBS站 (Thu Apr 11 12:44:20 2002), 转信
大概意思是说弥补IIS的最新十个安全漏洞。这些安全漏洞严重威胁到所有使用
WindowsNT或者Windows 2000的IIS服务器。其中一些漏洞将能远程执行攻击者代码，
并能够完全控制服务器。 快打布丁吧:
http://www.microsoft.com/technet/security/bulletin/MS02-018.asp
Cumulative Patch for Internet Information Services (Q319733)
Originally posted: April 10, 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: Ten new vulnerabilities, the most serious of which
could enable code of an attacker’s choice to be run on a server.
Recommendation: Customers using any of the affected products should install the
patch immediately.
Maximum Severity Rating: Critical
Affected Software:
Microsoft Internet Information Server 4.0
Microsoft Internet Information Services 5.0
Microsoft Internet Information Services 5.1
Note: Beta versions of .NET Server after Build 3605 contains fixes for all of
the vulnerabilities affecting IIS 6.0. As discussed in the FAQ, Microsoft is
working directly with the small number of customers who are using the .NET
Server beta version in
production environments to provide immediate remediation for them.
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 buffer overrun vulnerability involving the operation of the chunked encoding
transfer mechanism via Active Server Pages in IIS 4.0 and 5.0. An attacker who
exploited this vulnerability could overrun heap memory on the system, with the
result of
either causing the IIS service to fail or allowing code to be run on the
server.
A Microsoft-discovered vulnerability that is related to the preceding one, but
which lies elsewhere within the ASP data transfer mechanism. It could be
exploited in a similar manner as the preceding vulnerability, and would have
the same scope.
However, it affects IIS 4.0, 5.0, and 5.1.
A buffer overrun involving how IIS 4.0, 5.0 and 5.1 process HTTP header
information in certain cases. IIS performs a safety check prior to parsing the
fields in HTTP headers, to ensure that expected delimiter fields are present
and in reasonable
places. However, it is possible to spoof the check, and convince IIS that the
delimiters are present even when they are not. This flaw could enable an
attacker to create an URL whose HTTP header field values would overrun a buffer
used to process them.
A Microsoft-discovered buffer overrun vulnerability in IIS 4.0, 5.0 and 5.1
that results from an error in safety check that is performed during server-side
includes. In some cases, a user request for a web page is properly processed by
including the
file into an ASP script and processing it. Prior to processing the include
request, IIS performs an operation on the user-specified file name, designed to
ensure that the file name is valid and sized appropriately to fit in a static
buffer. However, in
some cases it could be possible to provide a bogus, extremely long file name in
a way that would pass the safety check, thereby resulting in a buffer overrun.
A buffer overrun affecting the HTR ISAPI extension in IIS 4.0 and 5.0. By
sending a series of specially malformed HTR requests, it could be possible to
either cause the IIS service to fail or, under a very difficult operational
scenario, to cause code
to run on the server.
A denial of service vulnerability involving the way IIS 4.0, 5.0, and 5.1
handle an error condition from ISAPI filters. At least one ISAPI filter (which
ships as part of FrontPage Server Extensions and ASP.NET), and possibly others,
generate an error
when a request is received containing an URL that exceeds the maximum length
set by the filter. In processing this error, the filter replaces the URL with a
null value. A flaw results because IIS attempts to process the URL in the
course of sending the
error message back to the requester, resulting in an access violation that
causes the IIS service to fail.
A denial of service vulnerability involving the way the FTP service in IIS 4.0,
5.0 and 5.1 handles a request for the status of the current FTP session. If an
attacker were able to establish an FTP session with an affected server, and
levied a status
request that created a particular error condition, a flaw in the FTP code would
prevent it from correctly reporting the error. Other code within the FTP
service would then attempt to use uninitialized data, with an access violation
as the result. This
would result in the disruption of not only FTP services, but also of web
services.
A trio of Cross-Site Scripting (CSS) vulnerabilities affecting IIS 4.0, 5.0 and
5.1: one involving the results page that’s returned when searching the IIS
Help Files, one involving HTTP error pages; and one involving the error message
that’s returned
to advise that a requested URL has been redirected. All 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.
Mitigating factors:
Buffer overrun in Chunked Encoding transfer:
On default installations of IIS 5.0 and 5.1, exploiting the vulnerability to
run code would grant the attacker the privileges of the IWAM_computername
account, which has only the privileges commensurate with those of an
interactively logged-on
unprivileged user.
The vulnerability requires that Active Server Pages (ASP) be enabled on the
system in order to be exploited. Version 1.0 of the IIS Lockdown Tool removes
ASP by default, and the current version (version 2.1) removes it by default if
Static Web Server
has been selected.
The URLScan tool can be configured to prevent chunked encoding requests. If
this has been done, the vulnerability could not be exploited.
Microsoft-discovered variant of Chunked Encoding buffer overrun:
This vulnerability is subject to exactly the same mitigating factors as the
buffer overrun in the Chunked Encoding transfer, with one exception. The
URLScan tool could not be used to protect against the vulnerability.
Buffer Overrun in HTTP header handling:
On default installations of IIS 5.0 and 5.1, exploiting the vulnerability to
run code would grant the attacker the privileges of the IWAM_computername
account, which has only the privileges commensurate with those of an
interactively logged-on
unprivileged user.
The vulnerability requires that Active Server Pages (ASP) be enabled on the
system in order to be exploited. Version 1.0 of the IIS Lockdown Tool removes
ASP by default, and the current version (version 2.1) removes it by default if
Static Web Server
has been selected.
The URLScan tool’s default ruleset would likely limit the attacker to using
this vulnerability for denial of service attacks only.
Buffer Overrun in ASP Server-Side Include Function:
On default installations of IIS 5.0 and 5.1, exploiting the vulnerability to
run code would grant the attacker the privileges of the IWAM_computername
account, which has only the privileges commensurate with those of an
interactively logged-on user.
The vulnerability requires that Active Server Pages (ASP) be enabled on the
system in order to be exploited. Version 1.0 of the IIS Lockdown Tool removes
ASP by default, and the current version (version 2.1) removes it by default if
Static Web Server
has been selected.
The URLScan tool’s default ruleset would likely limit the attacker to using
this vulnerability for denial of service attacks only.
Buffer overrun in HTR ISAPI extension:
Microsoft has long recommended disabling the HTR ISAPI extension. Systems on
which this has been done would be at no risk from the vulnerability. (All
versions of the IIS Lockdown Tool disable HTR support by default).
The URLScan tool, if using its default ruleset, would prevent this
vulnerability from being exploited to run code on the server even if HTR
support was enabled.
The vulnerability could only be used to run code on the server if the attacker
knew the locations of certain information in memory. In practice, the most
likely such situation would occur if the web server had never served any web
content since being
rebooted. In all other cases, it would only be possible to use the
vulnerability for denial of service attacks.
On default installations of IIS 5.0 and 5.1, exploiting the vulnerability to
run code would grant the attacker the privileges of the IWAM_computername
account, which has only the privileges commensurate with those of an
interactively logged-on user.
If the vulnerability were used in a denial of service attack, normal operation
could be restored on an IIS 4.0 server by restarting the IIS service; on IIS
5.0 and higher, the service would automatically restart itself.
Access violation in URL error handling:
An IIS 4.0 server could be put back into normal operation by restarting the
service. An IIS 5.0 or 5.1 server would automatically restart the service.
The vulnerability could only be used for denial of service attacks. There is no
capability to use the vulnerability to gain privileges on the system.
The sole ISAPI filter known to generate the error that results in the access
violation ships only as part of FrontPage Server Extensions and ASP.NET.
ASP.NET is not installed by default, and FPSE can be uninstalled if desired.
Denial of service via FTP Status request:
The IIS Lockdown Tool disables FTP support by default.
An IIS 4.0 server could be put back into normal operation by restarting the
service. An IIS 5.0 or 5.1 server would automatically restart the service.
The vulnerability could only be used for denial of service attacks. There is no
capability to use the vulnerability to gain privileges on the system.
Cross-site Scripting in IIS Help File search facility, HTTP Error Page, and
Redirect Response message:
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.
The Redirect Response vulnerability could only be exploited if the user was
running a browser other than Internet Explorer. IE does not actually render the
text in the Redirect Response, but instead recognizes it by its response header
and processes
the redirect without displaying any text.
Severity Rating:
Buffer overrun in ASP Chunked Encoding data transfer mechanism: Internet
Servers Intranet Servers Client Systems
IIS 4.0 Critical Critical None
IIS 5.0 Critical Critical None
IIS 5.1 None None None
Microsoft-discovered variant of ASP Chunked Encoding buffer overrun: Internet
Servers Intranet Servers Client Systems
IIS 4.0 Critical Critical None
IIS 5.0 Critical Critical None
IIS 5.1 Critical Critical None
Buffer Overrun in HTTP Header Handling: Internet Servers Intranet Servers
Client Systems
IIS 4.0 Critical Critical None
IIS 5.0 Critical Critical None
IIS 5.1 Critical Critical None
Buffer Overrun in ASP Server-Side Include Function: Internet Servers Intranet
Servers Client Systems
IIS 4.0 Critical Critical None
IIS 5.0 Critical Critical None
IIS 5.1 Critical Critical None
Buffer overrun in HTR ISAPI extension: Internet Servers Intranet Servers
Client Systems
IIS 4.0 Moderate Moderate None
IIS 5.0 Moderate Moderate None
IIS 5.1 None None None
Access violation in URL error handling: Internet Servers Intranet Servers
Client Systems
IIS 4.0 Moderate Moderate None
IIS 5.0 Moderate Moderate None
IIS 5.1 Moderate Moderate None
Denial of service via FTP status request: Internet Servers Intranet Servers
Client Systems
IIS 4.0 Moderate Moderate None
IIS 5.0 Moderate Moderate None
IIS 5.1 Moderate Moderate None
Cross-site Scripting in IIS Help File search facility: Internet Servers
Intranet Servers Client Systems
IIS 4.0 None None Moderate
IIS 5.0 None None Moderate
IIS 5.1 None None Moderate
Cross-site Scripting in HTTP Error Page: Internet Servers Intranet Servers
Client Systems
IIS 4.0 None None Moderate
IIS 5.0 None None Moderate
IIS 5.1 None None Moderate
Cross-site Scripting in Redirect Response message: 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 identifiers:
Buffer overrun in Chunked Encoding mechanism: CAN-2002-0079
Microsoft-discovered variant of Chunked Encoding buffer overrun: CAN-2002-0147
Buffer Overrun in HTTP Header handling: CAN-2002-0150
Buffer Overrun in ASP Server-Side Include Function: CAN-2002-0149
Buffer overrun in HTR ISAPI extension: CAN-2002-0071
Access violation in URL error handling: CAN-2002-0072
Denial of service via FTP status request: CAN-2002-0073
Cross-site Scripting in IIS Help File search facility: CAN-2002-0074
Cross-site Scripting in HTTP Error Page: CAN-2002-0148
Cross-site Scripting in Redirect Response message: CAN-2002-0075
Tested Versions:
The following table indicates which of the currently supported versions of IIS
are affected by the vulnerabilities. Versions prior to IIS 4.0 are no longer
supported and may or may not be affected by these vulnerabilities. IIS 6.0 is a
beta product and
is therefore not intended for use in production systems. A small number of
customers are deploying IIS 6.0 servers in product environments as part of a
joint program with Microsoft, and patches will be delivered directly to them.
IIS 4.0 IIS 5.0 IIS
5.1
Buffer overrun in Chunked Encoding mechanism Yes Yes No
Microsoft-discovered variant of Chunked Encoding buffer overrun Yes Yes Yes
Buffer Overrun in HTTP Header handling Yes Yes Yes
Buffer Overrun in ASP Server-Side Include Function Yes Yes Yes
Buffer overrun in HTR ISAPI extension Yes Yes No
Access violation in URL error handling Yes Yes Yes
Denial of service via FTP status request Yes Yes Yes
Cross-site Scripting in IIS Help File search No Yes Yes
Cross-site Scripting in HTTP Error Page Yes Yes Yes
Cross-site Scripting in Redirect Response message Yes Yes Yes
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 an attacker to gain control over a web server
running IIS 4.0 or 5.0.
A Microsoft-discovered vulnerability with the same risk and effect as the
preceding vulnerability, but which affects IIS 4.0, 5.0, and 5.1.
A vulnerability that could enable an attacker to gain control over a web server
running IIS 4.0 or 5.0.
A Microsoft-discovered vulnerability that could enable an attacker to gain
control over a web server running IIS 4.0, 5.0 or 5.1.
A vulnerability that could, under unusual conditions, enable an attacker to
gain control over a web server running IIS 4.0 or 5.0.
A vulnerability that could enable an attacker to prevent an IIS 4.0, 5.0 or 5.1
web server from providing service.
A vulnerability that could enable an attacker to prevent an FTP server on an
IIS 4.0, 5.0, or 5.1 server from providing service.
Three 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 a small number of fixes for issues that aren’t
security vulnerabilities. These are documented in Microsoft Knowledge Base
article Q319733
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. 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.
Buffer Overrun in Chunked Encoding Transfer (CVE-CAN-2002-0079)
What’s the scope of this 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
Customers who have used the IIS Lockdown Tool to configure their servers as
static web servers are already protected against the vulnerability. Likewise,
the URLScan tool can be configured to block the vulnerability, and affected
mechanism itself can
be disabled. However, because of the seriousness of the vulnerability, we do
recommend that all customers install the patch, including those who have
already taken these steps.
What causes the vulnerability?
The vulnerability results because of an arithmetic error in the ISAPI extension
that implements the Active Server Pages (ASP) 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 Active Server Pages.
What are Active Server Pages?
Active Server Pages (ASP) is a technology that allows web servers to
dynamically generate web applications. One way to visualize Active Server Pages
is consider them to be programs that resides on the web server; when a user
requests an ASP page, the
ASP ISAPI extension processes the ASP page, generates an HTML page, and sends
it to the user. The vulnerability in this case doesn’t involve the ASP
technology per se, but instead involves an error in how a standard type of data
transfer operation
called chunked encoding is implemented in 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 IIS 4.0 and 5.0 perform chunked encoding transfers?
There’s an arithmetic error in the IIS 4.0 and 5.0 Active Server Pages
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 on the system.
This is a critical point, because it goes to the heart of why this
vulnerability poses such a serious threat to servers. This vulnerability is an
example of so-called heap overrun; these are frequently difficult or impossible
to exploit, because of the
dynamic nature of system memory. 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 ASP ISAPI extension, ASP.DLL. The privileges that the
attacker could gain would depend on the version of IIS in use on the server:
On IIS 4.0, ASP.DLL 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, ASP.DLL 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 ASP.DLL to run out-of-process?
Yes. Microsoft has long recommended that, whenever possible, IIS 4.0 should be
configured to run ASP.DLL and other components out-of-process. This not only
improves security, but stability as well. There is, however, a performance
penalty associated
with running out of process.
I don’t use Active Server Pages. Would disabling the functionality altogether
protect my server?
Yes. In fact, Version 1.0 of the IIS Lockdown Tool disabled ASP by default. The
current version of the Tool, version 2.1, provides a number of different server
roles. Selecting “Static Web Server” will disable ASP by default.
I’ve deployed the URLScan Tool on my server. Will it protect my system against
this vulnerability?
By default, it would not. However, it would be possible add a rule that would
block chunked encoding requests. Just add 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”).
Microsoft has release an updated version of the URLScan that implements this
rule by default, as well as improving the protection the tool can provide. The
updated tool is available for download at
http://www.microsoft.com/technet/security/URLScan.asp.
How does the patch eliminate this vulnerability?
The patch eliminates the arithmetic error that causes the vulnerability.
Microsoft-discovered variant of Chunked Encoding buffer overrun
(CVE-CAN-2002-0147)
What’s the scope of this vulnerability?
This vulnerability is identical to the preceding one in scope, effect, and
remediation. There are only two significant differences:
This vulnerability affects additional versions of IIS. Specifically, it affects
IIS 4.0, 5.0 and 5.1.
It cannot be blocked by URLScan.
What causes this vulnerability?
This vulnerability results because of a handling error in the allocation of
buffers for data transfers. Although it involves a similar functionality as
preceding one, and has the same overall effect, there are nevertheless some
important differences
between the two vulnerabilities.
What are the differences between this vulnerability and the preceding one?
There are two primary differences. First, where IIS 5.1 is not affected by the
preceding one, it is affected by this one. Second, unlike the preceding
vulnerability, this one could not be blocked via URLScan.
How was this vulnerability found?
Microsoft discovered this vulnerability through code inspection as part of the
investigation of the preceding one.
Buffer Overrun in ASP Server-Side Include Function (CVE-CAN-2002-0149)
What’s the scope of this vulnerability?
This is a buffer overrun vulnerability affecting IIS 4.0, 5.0 and 5.1. 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 and 5.1
Customers who have used the IIS Lockdown Tool to configure their servers as
static web servers are already protected against the vulnerability. Likewise,
the URLScan tool, when deployed with the default ruleset, would make it
difficult to use the
vulnerability to gain control of the server, and likely reduce it to a denial
of service attack only.
What causes the vulnerability?
The vulnerability results because of a logic error in a function that handles
server-side file includes for Active Server Pages. The result of the error is
that the function could conclude that it is safe to store the name of a
specified server-side
file in a particular buffer, when in actuality the filename is longer than the
buffer
What are server-side file includes?
Frequently, developers need to be able to incorporate a file into a program –
for instance, as a way of reusing existing code. File includes provide a way to
do this. The developer specifies what file should be included in the program,
and at what
point, and the contents of the file are treated as though they were part of the
program.
ASP, like most programming languages, supports file includes. In the case of
ASP, the included files come from the web server itself, so they’re known as
server-side file includes. When an ASP script runs, a pre-processing step
handles any file
includes, after which point the ASP ISAPI filter processes the result.
Can a visitor to a web site request a server-side include?
No. After all, a web site visitor should never actually be involved in the
operation of ASP scripts – all processing should occur on the server. However,
it is possible for user actions to have the effect of causing a file include on
the server to
happen. This vulnerability involves the operation of IIS when this is done, and
in a particular way.
What’s wrong with how IIS handles server-side includes?
In some cases, requesting a particular web page will cause it to be included
within an ASP script as part of its processing. Because this involves putting
user input into a buffer, IIS always performs a check beforehand, designed to
make sure the input
is valid. Specifically, it performs an operation on the file name that should
only succeed if the file name is valid.
A security vulnerability results because it’s possible to levy a request that
includes a very long, invalid file name, but do it in a way that has two
effects. First, the ASP ISAPI extension concludes that the filename needs to be
processed as part of
an ASP file, and does a server-side include. Second, the filename evades the
safety check. The result is that the file name – which is longer than the
buffer allocated to hold it – causes a buffer overrun in the ASP file when it’
s processed.
What would the vulnerability 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 could establish a session with an affected web server could
exploit the vulnerability.
If the vulnerability were exploited to cause the IIS server 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
and 5.1, the service would automatically restart itself.
If the vulnerability were exploited to change the operation of the server
software, what would the attacker be able to do?
If exploited in this way, the attacker could gain the same privileges as
discussed above:
On IIS 4.0, the attacker could gain complete control over the server
On IIS 5.0 and 5.1, the attacker could gain the privileges associated with the
Web Application Manager – essentially, those of an unprivileged user.
Would the IIS Lockdown Tool help protect my server?
The vulnerability could only be exploited if Active Server Pages are enabled on
the server. Version 1.0 of the IIS Lockdown Tool disables ASP by default. The
current version of the Tool, version 2.1, provides a number of different server
roles.
Selecting “Static Web Server” disables ASP by default.
Would the URLScan tool protect my system against this vulnerability?
It wouldn’t offer total protection, but it would significantly reduce the
scope of the vulnerability. By default, URLScan blocks all URLs that contain
non-ASCII data. This would not prevent an attacker from causing the service to
fail – overrunning
the buffer with virtually any data would accomplish that goal. However, it
would make it difficult to exploit the vulnerability to alter the operation of
the server software, because the attacker would need to construct valid
executable code using only
ASCII data.
How was this vulnerability found?
Microsoft discovered this vulnerability as part of a security review.
How does the patch eliminate the vulnerability?
The patch correct the truncation error, thereby ensuring that the URLs under
discussion here will not be passed to the function.
Buffer Overrun in HTTP Header Handling (CVE-CAN-2002-0149)
What’s the scope of this vulnerability?
This is a buffer overrun vulnerability affecting IIS 4.0, 5.0 and 5.1. 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 and 5.1.
Customers who have used the IIS Lockdown Tool to configure their servers as
static web servers are already protected against the vulnerability. Likewise,
the URLScan tool, when deployed with the default ruleset, would prevent this
vulnerability from
being used to gain control of the server, and reduce it to a denial of service
attack only.
What causes the vulnerability?
The vulnerability results because of an error that occurs when Active Server
Pages parse HTTP header information. An initial check is performed, with the
goal of ensuring that required delimiters are present in the information and in
reasonable
locations before moving the information in a buffer for processing. However,
the check can be spoofed, with a buffer overrun as the result.
What are HTTP headers?
When a client sends a request to a web server, it needs a way to give the web
server specific information about the request. For instance, it needs to
indicate how data in the request has been formatted, what web browser the
client is using, what
action the server should perform, and so on. All of this information is
specified via fields in the request known as HTTP headers.
What’s wrong with the way IIS handles HTTP headers?
When IIS receives an HTTP request, it must parse the headers so it can
interpret them and take the appropriate action. This is done by breaking the
headers into their constituent parts and putting each in a buffer; IIS
determines where each of the
parts ends by looking for a delimiting character.
IIS checks before performing this operation, to make sure that the delimiting
characters are really present, and located at appropriate places within the
request. However, by constructing a request in a particular way, it’s possible
to spoof this
check, and make IIS conclude that the delimiting characters are present when in
fact they aren’t.
Why does this result in a security vulnerability?
The purpose of the check is to ensure that IIS never copies more information
into the buffer than it’s designed to hold. However, by spoofing the checks,
this protection could be bypassed, resulting in a buffer overrun.
Specifically, suppose an attacker sent a request that contained a large amount
of data within the HTTP header fields. Ordinarily, IIS would detect that the
data didn’t contain the expected delimiters, and that the fields were
therefore too large to
fit safely in the buffers. It would therefore reject the request. However, if
the request was constructed to exploit this vulnerability, IIS would
incorrectly conclude that the request was well-formed, and would copy the
fields into the buffer, thereby
overrunning it.
What would the vulnerability 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 could establish a session with an affected web server could
exploit the vulnerability.
If the vulnerability were exploited to cause the IIS server 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
and 5.1, the service would automatically restart itself.
If the vulnerability were exploited to change the operation of the server
software, what would the attacker be able to do?
If exploited in this way, the attacker could gain the same privileges as
discussed above:
On IIS 4.0, the attacker could gain complete control over the server
On IIS 5.0 and 5.1, the attacker could gain the privileges associated with the
Web Application Manager – essentially, those of an unprivileged user.
Would the IIS Lockdown Tool help protect my server?
The vulnerability could only be exploited if Active Server Pages are enabled on
the server. Version 1.0 of the IIS Lockdown Tool disables ASP by default. The
current version of the Tool, version 2.1, provides a number of different server
roles.
Selecting “Static Web Server” disables ASP by default.
Would the URLScan tool protect my system against this vulnerability?
It wouldn’t offer total protection, but it would significantly reduce the
scope of the vulnerability. By default, URLScan blocks all URLs that contain
non-ASCII data. This would not prevent an attacker from causing the service to
fail – overrunning
the buffer with virtually any data would accomplish that goal. However, it
would make it difficult to exploit the vulnerability to alter the operation of
the server software, because the attacker would need to construct valid
executable code using only
ASCII data.
How does the patch eliminate the vulnerability?
The patch corrects the checking mechanism, and ensures that it’s performed
correctly in all cases.
Buffer overrun in HTR ISAPI extension (CVE-CAN-2002-0071)
What’s the scope of this 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 cause it
to temporarily stop providing web services or, in very unusual cases, could
gain control of
the server.
There are a number of factors that tend to reduce the severity of this
vulnerability:
The most likely effect of exploiting this vulnerability would be to disrupt
service on the web server. While it would be possible to use the vulnerability
to gain control over the server, it would in most cases require fortuitous
circumstances for the
attacker.
The component containing the vulnerability is removed by default by the IIS
Lockdown Tool.
The URLScan tool’s default configuration would prevent the vulnerability from
being exploited.
What causes the vulnerability?
The vulnerability results because the ISAPI extension that implements HTR
scripting contains an off-by-one error when calculating the size of a buffer
for storing an input value. If a request for an HTR script were malformed in a
particular way, it
would be possible to abuse the miscalculation and conduct a buffer overrun
attack. In the least serious case, this could result in the failure of the IIS
service; in the most serious case (which would be difficult to exploit), it
could allow code to be
run on the server.
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 disable 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’s wrong with the HTR ISAPI extension?
When the HTR ISAPI extension receives a request to run a script, it calculates
the size of the buffer that’s needed to contain the request. However, it
miscalculates this value, with the result that it creates a buffer one byte
smaller than needed. By
sending a series of HTR requests, all malformed in particular ways, it could be
possible to use the vulnerability to overwrite memory on the server.
What would this enable an attacker to do?
An attacker could exploit this vulnerability in either of two ways. By sending
a series of requests that simply overran the buffer with random data, the
attacker could cause the service to fail. However, by carefully selecting the
data, it could be
possible – although operationally difficult – to modify the operation of the
IIS service to perform tasks of the attacker’s choice.
If the attacker used this vulnerability to cause the service to fail, what
would be the result?
If exploited against an IIS 4.0 server, the attack would prevent the server
from handling web requests until the administrator restarted the IIS service.
If exploited against an IIS 5.0 or 5.1 server, the outage would be only
temporary, as the IIS
service would automatically restart itself. In either case, any web sessions
that were underway when the service failed would be terminated.
If the attacker used this vulnerability to modify the operation of the service,
would what be the result?
If exploited in this way, the attacker could gain the same privileges as
discussed above:
On IIS 4.0, the attacker could gain complete control over the server
On IIS 5.0, the attacker could gain the privileges associated with the Web
Application Manager – essentially, those of an unprivileged user.
How difficult would it be to exploit the vulnerability to gain control over the
server?
Like the vulnerability discussed above, this is a heap overrun. However, this
one would be more difficult to exploit. For instance, it would be more
difficult from a technical standpoint to write an exploit tool that takes
advantage of a one-byte heap
overrun.
Even if an exploit tool were available, the vulnerability could only be
exploited under certain conditions. In practical terms, most of these
conditions would only be present if the server hadn’t serviced any web
requests since the last time it was
booted, and even then the attacker would need specific information about the
software running on the server. Note, however, that none of these factors would
be impossible to overcome, given the right circumstances.
I’ve run the IIS Lockdown Tool. Am I vulnerable to this issue?
By default, the IIS Lockdown Tool disables support for HTR. The vulnerability
could not be exploited against a server on which HTR support was disabled.
I have URLScan running. Am I vulnerable to this issue?
URLScan’s default ruleset would prevent this vulnerability from being
exploited, even if the server was otherwise vulnerable. We do, however,
recommend applying the patch on any server on which HTR is enabled, even if
URLScan is protecting it.
I’m running a system that’s susceptible to the vulnerability. What should I
do?
The best course of action is to remove HTR support altogether, by unmapping the
HTR ISAPI extension. (The simplest way to do this is via the IIS Lockdown Tool)
. We recommend retaining HTR support only if there’s a business-critical need
for it.
Even after removing HTR, we still recommend applying the patch. First, it fixes
vulnerabilities in addition to this one. Second, applying the patch will ensure
that the server would still be protected even if HTR support were inadvertently
re-enabled
at some future point.
How does the patch eliminate the vulnerability?
The patch corrects the miscalculation in the HTR ISAPI extension, and ensures
that it allocates a buffer that matches the size of the incoming request.
Access violation in URL error handling (CVE-CAN-2002-0072)
What’s the scope of this vulnerability?
This is a denial of service vulnerability affecting IIS 4.0, 5.0 and 5.1. By
exploiting this vulnerability, an attacker could temporarily prevent a web
server from providing web services.
The vulnerability would not allow any data on the system to be compromised, nor
would it enable the attacker to gain any privileges on the system. Microsoft’s
investigations to date suggest that this vulnerability only occurs in cases
where Front Page
Server Extensions (FPSE) or ASP.NET are installed on the system, although it is
possible that it may also occur under other conditions as well.
What causes the vulnerability?
The vulnerability occurs because IIS incorrectly handles the error condition
that results when one of the ISAPI filters installed by Front Page Server
Extensions and ASP.NET receives an URL that exceeds the maximum allowable
length. Although the
problem lies within IIS, and therefore could also occur in cases involving
additional ISAPI filters, Microsoft’s investigations to date have not revealed
any others in which this occurs.
What’s an ISAPI filter?
As discussed above, an ISAPI filter is a .dll installed to extend the
functionality available through a web server. The specific filter at issue in
this case is one installed by FPSE and ASP.NET, although others could also be
involved as well.
What is FPSE?
FrontPage Server Extensions (FPSE) is a set of tools that can be installed on a
web server to allow authorized personnel to manage the server, add or change
content, and perform other tasks.
What is ASP.NET?
ASP.NET is a development platform that allows web applications to be built
easily and rapidly. ASP.NET can be thought of as a superset of ASP -- existing
ASP programs can be ported directly to ASP.NET, but it also provides new,
extended functionality.
What’s wrong with FPSE and ASP.NET?
Nothing. The problem in this case involves how IIS handles a particular type of
error condition that can be generated by ISAPI filters. It happens that the
only ISAPI filters Microsoft has identified so far that actually generate the
error condition
are associated with FPSE and ASP.NET. However, the problem doesn’t lie in the
ISAPI filter, but rather in the way IIS handles the error condition.
What’s the error condition, and why does it cause the IIS service to fail? The
error in this case occurs when either of the ISAPI filters receive a request
containing an URL that exceeds the maximum length. When this happens, the
filter fails the
request, and sets the URL to a null value. The vulnerability results because
IIS, before sending the response back to the requester, tries to use the URL.
This causes an access violation that results in the failure of the IIS service.
What would this enable an attacker to do?
An attacker who exploited this vulnerability would be able to cause the IIS
service to fail. This would have the effect of terminating any sessions that
were in process at the time, and preventing any new ones until the service was
restarted.
How might an attacker exploit the vulnerability?
An attacker could exploit the vulnerability by sending to an affected server a
request that would be processed by either of the ISAPI filters mentioned above,
and including an URL that exceeds the maximum length for the filter. (Likewise,
if there were
other ISAPI filters installed on the system that can generate the same error
condition, the attacker could send a request to one of them).
What would be required to resume normal operation?
On IIS 4.0, the operator would need to restart the service. On IIS 5.0 and 5.1,
the service would automatically restart itself.
Could the attacker gain any other privileges on the server via this
vulnerability?
No. This is strictly a denial of service vulnerability; there is no capability
to change content on the server, manage it, or take any other actions.
I haven’t installed FPSE on my server. Could I be affected by the
vulnerability?
Some of the Server Extensions install as part of IIS 4.0, 5.0 and 5.1 by
default, and others must be installed separately. The ISAPI filter at issue
here installs by default, so a server would be affected unless the
administrator had removed FPSE.
(FPSE can be removed via the Add/Remove Programs applet in Control Panel). Even
if FPSE has been removed, keep in mind that it could be possible for a server
to have other ISAPI filters installed that would generate the error condition
that causes IIS
to fail.
I haven't installed ASP.NET on my server. Could I be affected by the
vulnerability?
ASP.NET does not install by default as part of IIS. However, even if ASP.NET is
not installed on the system, FPSE would be, as discussed in the preceding
paragraph.
How does the patch eliminate this vulnerability?
The patch cause IIS to check the URL when processing the error at issue here,
and to not attempt to process it.
Denial of service via FTP status request (CVE-CAN-2002-0073)
What’s the scope of this vulnerability?
This is a denial of service vulnerability affecting IIS 4.0, 5.0 and 5.1. By
exploiting this vulnerability, an attacker could temporarily prevent a web
server from providing web services.
The vulnerability could only be exploited if the web server were also
configured to provide FTP services. IIS 4.0 installs FTP services by default,
but IIS 5.0 and 5.1 do not. The IIS Lockdown Tool disables FTP support by
default. The vulnerability
would not allow any data on the system to be compromised, nor would it enable
the attacker to gain any privileges on the system.
What causes the vulnerability?
The vulnerability results because the FTP implementation in IIS 4.0, 5.0 and
5.1 does not correctly handle a request for the status of the connection, if
the request has been malformed in a particular way. Receiving such a request
would result in the
failure of the IIS service.
What is FTP?
File Transfer Protocol (FTP) is an industry standard protocol (specified in RFC
959) that allows users to post files to or retrieve files from a server. All
versions of IIS include an implementation of the protocol.
What’s wrong with the FTP implementation in IIS 4.0, 5.0 and 5.1?
They contain an error in the way they handle a request for the status of an
ongoing FTP connection. Specifically, including certain characters in the
request creates an error condition, but this fact isn’t correctly reported
back to the software
module that relayed the user’s request. The result is that the calling module
uses uninitialized data, thereby causing an access violation.
What would this enable an attacker to do?
FTP services are provided by the IIS service itself, so an attacker who
exploited this vulnerability would be able to disrupt not only FTP services but
web services as well. This would have the effect of terminating any sessions
that were in effect at
the time of the attack.
Who could exploit this vulnerability?
Any user who was able to establish an FTP session with an affected server could
exploit the vulnerability. The status request that contains the flaw can only
be levied as part of an already existing session.
What would be required to resume normal operation?
On an IIS 4.0 server, the operator would need to restart the IIS service. On
IIS 5.0 and 5.1 servers, the service would automatically restart itself.
What’s the significance of the need for the attacker to be able to establish a
session with the server?
It means that an attacker could not simply conduct a “drive-by” attack and
send data to the server. The FTP service would need to be enabled and running,
and the attacker would either need logon credentials, or the server would need
to be configured
to allow anonymous logon.
Does FTP install and run by default?
It is enabled and running by default as part of IIS 4.0, but not as part of IIS
5.0 or 5.1. It’s also worth noting that the IIS Lockdown Tool disables FTP by
default.
If FTP is running, is anonymous logon enabled by default?
Yes. It’s always a good idea to consider whether you really want to allow
anonymous access to your FTP server, and to disable it if this isn’t the case.
How does the patch eliminate the vulnerability?
The patch causes the FTP service to correctly handle the command at issue here.
Cross-site Scripting in IIS Help File search facility, Redirect Response
message, and HTTP Error Page (CVE-CAN-2002-0074, 0075, 0148)
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 opened an HTML mail or
visited a malicious user’s web site – the code could not be “injected” into
an existing session. In one of the two cases here, even if an attacker did
exploit the
vulnerability, it would have no effect on a user running IE. 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 “<” or “>”. A full description of
the characters
that should be filtered is available in Knowledge Base article Q252985.
What’s wrong with IIS?
Three services provided by IIS don’t properly filter their inputs, and as a
result could be used in a cross-site scripting attack. The services are:
A search facility that allows IIS help files to be searched. The facility is
only provided in IIS 5.0 and 5.1, so only these versions are affected by the
vulnerability.
A message that’s returned when someone requests a web page that’s been moved
to a new location. (Such a message is known as a redirect response). The
versions of this message that are produced by IIS 4.0, 5.0 and 5.1 are affected
by the
vulnerability. However, a successful attack could only be carried out via this
message if the target of the attack was running a browser other than Internet
Explorer.
Several error messages that are returned when a user's request for a web page
results in an error. The default versions of these messages produced in IIS 4.0
and 5.0 are affected by the vulnerability.
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.
You said above that one of the vulnerabilities could only be exploited if the
user was using a browser other than IE. Why is this?
In the case of the error message that’s returned when a web page has been
moved, IE doesn’t actually display the text in the error message. Instead, it
processes information elsewhere in the server’s response and immediately takes
the user to the
new page. As a result, it’s not susceptible to the cross-site scripting error.
Other browsers may or may not work similarly, depending on how they implement
the handling of redirect responses.
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 eliminate the vulnerability?
The patch eliminates the vulnerability by ensuring that both of the services
discussed above properly filter their inputs before using them.
Cumulative Patch for Internet Information Services (Q319733)
Originally posted: April 10, 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: Ten new vulnerabilities, the most serious of
which could enable code of an attacker’s choice to be run on a server.
Recommendation: Customers using any of the affected products should
install the patch immediately.
Maximum Severity Rating: Critical
Affected Software:
Microsoft Internet Information Server 4.0
Microsoft Internet Information Services 5.0
Microsoft Internet Information Services 5.1
Note: Beta versions of .NET Server after Build 3605 contains fixes for
all of the vulnerabilities affecting IIS 6.0. As discussed in the FAQ,
Microsoft is working directly with the small number of customers who are
using the .NET Server beta version in production environments to
provide immediate remediation for them.
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 buffer overrun vulnerability involving the operation of the chunked
encoding transfer mechanism via Active Server Pages in IIS 4.0 and 5.0.
An attacker who exploited this vulnerability could overrun heap
memory on the system, with the result of either causing the IIS
service to fail or allowing code to be run on the server.
A Microsoft-discovered vulnerability that is related to the preceding
one, but which lies elsewhere within the ASP data transfer mechanism. It
could be exploited in a similar manner as the preceding vulnerability,
and would have the same scope. However, it affects IIS 4.0, 5.0, and
5.1.
A buffer overrun involving how IIS 4.0, 5.0 and 5.1 process HTTP
header information in certain cases. IIS performs a safety check prior
to parsing the fields in HTTP headers, to ensure that expected delimiter
fields are present and in reasonable places. However, it is possible to
spoof the check, and convince IIS that the delimiters are present
even when they are not. This flaw could enable an attacker to create
an URL whose HTTP header field values would overrun a buffer used to
process them.
A Microsoft-discovered buffer overrun vulnerability in IIS 4.0, 5.0
and 5.1 that results from an error in safety check that is performed
during server-side includes. In some cases, a user request for a web
page is properly processed by including the file into an ASP script
and processing it. Prior to processing the include request, IIS performs
an operation on the user-specified file name, designed to ensure that
the file name is valid and sized appropriately to fit in a static
buffer. However, in some cases it could be possible to provide a bogus,
extremely long file name in a way that would pass the safety check,
thereby resulting in a buffer overrun.
A buffer overrun affecting the HTR ISAPI extension in IIS 4.0 and 5.0.
By sending a series of specially malformed HTR requests, it could be
possible to either cause the IIS service to fail or, under a very
difficult operational scenario, to cause code to run on the server.
A denial of service vulnerability involving the way IIS 4.0, 5.0, and
5.1 handle an error condition from ISAPI filters. At least one ISAPI
filter (which ships as part of FrontPage Server Extensions and ASP.NET),
and possibly others, generate an error when a request is received
containing an URL that exceeds the maximum length set by the filter.
In processing this error, the filter replaces the URL with a null value.
A flaw results because IIS attempts to process the URL in the course of
sending the error message back to the requester, resulting in an access
violation that causes the IIS service to fail.
A denial of service vulnerability involving the way the FTP service in
IIS 4.0, 5.0 and 5.1 handles a request for the status of the current FTP
session. If an attacker were able to establish an FTP session with an
affected server, and levied a status request that created a particular
error condition, a flaw in the FTP code would prevent it from
correctly reporting the error. Other code within the FTP service would
then attempt to use uninitialized data, with an access violation as
the result. This would result in the disruption of not only FTP
services, but also of web services.
A trio of Cross-Site Scripting (CSS) vulnerabilities affecting IIS 4.0,
5.0 and 5.1: one involving the results page that’s returned when
searching the IIS Help Files, one involving HTTP error pages; and one
involving the error message that’s returned to advise that a
requested URL has been redirected. All 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.
Mitigating factors:
Buffer overrun in Chunked Encoding transfer:
On default installations of IIS 5.0 and 5.1, exploiting the
vulnerability to run code would grant the attacker the privileges of the
IWAM_computername account, which has only the privileges commensurate
with those of an interactively logged-on unprivileged user.
The vulnerability requires that Active Server Pages (ASP) be enabled
on the system in order to be exploited. Version 1.0 of the IIS
Lockdown Tool removes ASP by default, and the current version (version
2.1) removes it by default if Static Web Server has been selected.
The URLScan tool can be configured to prevent chunked encoding requests.
If this has been done, the vulnerability could not be exploited.
Microsoft-discovered variant of Chunked Encoding buffer overrun:
This vulnerability is subject to exactly the same mitigating factors
as the buffer overrun in the Chunked Encoding transfer, with one
exception. The URLScan tool could not be used to protect against the
vulnerability.
Buffer Overrun in HTTP header handling:
On default installations of IIS 5.0 and 5.1, exploiting the
vulnerability to run code would grant the attacker the privileges of the
IWAM_computername account, which has only the privileges commensurate
with those of an interactively logged-on unprivileged user.
The vulnerability requires that Active Server Pages (ASP) be enabled
on the system in order to be exploited. Version 1.0 of the IIS
Lockdown Tool removes ASP by default, and the current version (version
2.1) removes it by default if Static Web Server has been selected.
The URLScan tool’s default ruleset would likely limit the attacker to
using this vulnerability for denial of service attacks only.
Buffer Overrun in ASP Server-Side Include Function:
On default installations of IIS 5.0 and 5.1, exploiting the
vulnerability to run code would grant the attacker the privileges of the
IWAM_computername account, which has only the privileges commensurate
with those of an interactively logged-on user.
The vulnerability requires that Active Server Pages (ASP) be enabled
on the system in order to be exploited. Version 1.0 of the IIS
Lockdown Tool removes ASP by default, and the current version (version
2.1) removes it by default if Static Web Server has been selected.
The URLScan tool’s default ruleset would likely limit the attacker to
using this vulnerability for denial of service attacks only.
Buffer overrun in HTR ISAPI extension:
Microsoft has long recommended disabling the HTR ISAPI extension.
Systems on which this has been done would be at no risk from the
vulnerability. (All versions of the IIS Lockdown Tool disable HTR
support by default).
The URLScan tool, if using its default ruleset, would prevent this
vulnerability from being exploited to run code on the server even if HTR
support was enabled.
The vulnerability could only be used to run code on the server if the
attacker knew the locations of certain information in memory. In
practice, the most likely such situation would occur if the web server
had never served any web content since being rebooted. In all other
cases, it would only be possible to use the vulnerability for denial
of service attacks.
On default installations of IIS 5.0 and 5.1, exploiting the
vulnerability to run code would grant the attacker the privileges of the
IWAM_computername account, which has only the privileges commensurate
with those of an interactively logged-on user.
If the vulnerability were used in a denial of service attack, normal
operation could be restored on an IIS 4.0 server by restarting the IIS
service; on IIS 5.0 and higher, the service would automatically
restart itself.
Access violation in URL error handling:
An IIS 4.0 server could be put back into normal operation by
restarting the service. An IIS 5.0 or 5.1 server would automatically
restart the service.
The vulnerability could only be used for denial of service attacks.
There is no capability to use the vulnerability to gain privileges on
the system.
The sole ISAPI filter known to generate the error that results in the
access violation ships only as part of FrontPage Server Extensions and
ASP.NET. ASP.NET is not installed by default, and FPSE can be
uninstalled if desired.
Denial of service via FTP Status request:
The IIS Lockdown Tool disables FTP support by default.
An IIS 4.0 server could be put back into normal operation by
restarting the service. An IIS 5.0 or 5.1 server would automatically
restart the service.
The vulnerability could only be used for denial of service attacks.
There is no capability to use the vulnerability to gain privileges on
the system.
Cross-site Scripting in IIS Help File search facility, HTTP Error Page,
and Redirect Response message:
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.
The Redirect Response vulnerability could only be exploited if the
user was running a browser other than Internet Explorer. IE does not
actually render the text in the Redirect Response, but instead
recognizes it by its response header and processes the redirect
without displaying any text.
Severity Rating:
Buffer overrun in ASP Chunked Encoding data transfer mechanism:
Internet Servers Intranet Servers Client Systems
IIS 4.0 Critical Critical None
IIS 5.0 Critical Critical None
IIS 5.1 None None None
Microsoft-discovered variant of ASP Chunked Encoding buffer overrun:
Internet Servers Intranet Servers Client Systems
IIS 4.0 Critical Critical None
IIS 5.0 Critical Critical None
IIS 5.1 Critical Critical None
Buffer Overrun in HTTP Header Handling: Internet Servers Intranet
Servers Client Systems
IIS 4.0 Critical Critical None
IIS 5.0 Critical Critical None
IIS 5.1 Critical Critical None
Buffer Overrun in ASP Server-Side Include Function: Internet Servers
Intranet Servers Client Systems
IIS 4.0 Critical Critical None
IIS 5.0 Critical Critical None
IIS 5.1 Critical Critical None
Buffer overrun in HTR ISAPI extension: Internet Servers Intranet
Servers Client Systems
IIS 4.0 Moderate Moderate None
IIS 5.0 Moderate Moderate None
IIS 5.1 None None None
Access violation in URL error handling: Internet Servers Intranet
Servers Client Systems
IIS 4.0 Moderate Moderate None
IIS 5.0 Moderate Moderate None
IIS 5.1 Moderate Moderate None
Denial of service via FTP status request: Internet Servers Intranet
Servers Client Systems
IIS 4.0 Moderate Moderate None
IIS 5.0 Moderate Moderate None
IIS 5.1 Moderate Moderate None
Cross-site Scripting in IIS Help File search facility: Internet Servers
Intranet Servers Client Systems
IIS 4.0 None None Moderate
IIS 5.0 None None Moderate
IIS 5.1 None None Moderate
Cross-site Scripting in HTTP Error Page: Internet Servers Intranet
Servers Client Systems
IIS 4.0 None None Moderate
IIS 5.0 None None Moderate
IIS 5.1 None None Moderate
Cross-site Scripting in Redirect Response message: 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 identifiers:
Buffer overrun in Chunked Encoding mechanism: CAN-2002-0079
Microsoft-discovered variant of Chunked Encoding buffer overrun:
CAN-2002-0147
Buffer Overrun in HTTP Header handling: CAN-2002-0150
Buffer Overrun in ASP Server-Side Include Function: CAN-2002-0149
Buffer overrun in HTR ISAPI extension: CAN-2002-0071
Access violation in URL error handling: CAN-2002-0072
Denial of service via FTP status request: CAN-2002-0073
Cross-site Scripting in IIS Help File search facility: CAN-2002-0074
Cross-site Scripting in HTTP Error Page: CAN-2002-0148
Cross-site Scripting in Redirect Response message: CAN-2002-0075
Tested Versions:
The following table indicates which of the currently supported
versions of IIS are affected by the vulnerabilities. Versions prior to
IIS 4.0 are no longer supported and may or may not be affected by
these vulnerabilities. IIS 6.0 is a beta product and is therefore not
intended for use in production systems. A small number of customers
are deploying IIS 6.0 servers in product environments as part of a joint
program with Microsoft, and patches will be delivered directly to them.
IIS 4.0 IIS 5.0 IIS 5.1
Buffer overrun in Chunked Encoding mechanism Yes Yes No
Microsoft-discovered variant of Chunked Encoding buffer overrun Yes
Yes Yes
Buffer Overrun in HTTP Header handling Yes Yes Yes
Buffer Overrun in ASP Server-Side Include Function Yes Yes Yes
Buffer overrun in HTR ISAPI extension Yes Yes No
Access violation in URL error handling Yes Yes Yes
Denial of service via FTP status request Yes Yes Yes
Cross-site Scripting in IIS Help File search No Yes Yes
Cross-site Scripting in HTTP Error Page Yes Yes Yes
Cross-site Scripting in Redirect Response message Yes Yes Yes
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 an attacker to gain control over a web
server running IIS 4.0 or 5.0.
A Microsoft-discovered vulnerability with the same risk and effect as
the preceding vulnerability, but which affects IIS 4.0, 5.0, and 5.1.
A vulnerability that could enable an attacker to gain control over a web
server running IIS 4.0 or 5.0.
A Microsoft-discovered vulnerability that could enable an attacker to
gain control over a web server running IIS 4.0, 5.0 or 5.1.
A vulnerability that could, under unusual conditions, enable an attacker
to gain control over a web server running IIS 4.0 or 5.0.
A vulnerability that could enable an attacker to prevent an IIS 4.0, 5.0
or 5.1 web server from providing service.
A vulnerability that could enable an attacker to prevent an FTP server
on an IIS 4.0, 5.0, or 5.1 server from providing service.
Three 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 a small number of fixes for issues that
aren’t security vulnerabilities. These are documented in Microsoft
Knowledge Base article Q319733
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. 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.
Buffer Overrun in Chunked Encoding Transfer (CVE-CAN-2002-0079)
What’s the scope of this 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
Customers who have used the IIS Lockdown Tool to configure their servers
as static web servers are already protected against the vulnerability.
Likewise, the URLScan tool can be configured to block the
vulnerability, and affected mechanism itself can be disabled. However,
because of the seriousness of the vulnerability, we do recommend that
all customers install the patch, including those who have already
taken these steps.
What causes the vulnerability?
The vulnerability results because of an arithmetic error in the ISAPI
extension that implements the Active Server Pages (ASP) 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 Active Server Pages.
What are Active Server Pages?
Active Server Pages (ASP) is a technology that allows web servers to
dynamically generate web applications. One way to visualize Active
Server Pages is consider them to be programs that resides on the web
server; when a user requests an ASP page, the ASP ISAPI extension
processes the ASP page, generates an HTML page, and sends it to the
user. The vulnerability in this case doesn’t involve the ASP technology
per se, but instead involves an error in how a standard type of data
transfer operation called chunked encoding is implemented in 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 IIS 4.0 and 5.0 perform chunked encoding
transfers?
There’s an arithmetic error in the IIS 4.0 and 5.0 Active Server
Pages 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 on the system.
This is a critical point, because it goes to the heart of why this
vulnerability poses such a serious threat to servers. This vulnerability
is an example of so-called heap overrun; these are frequently difficult
or impossible to exploit, because of the dynamic nature of system
memory. 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 ASP ISAPI extension, ASP.DLL. The
privileges that the attacker could gain would depend on the version of
IIS in use on the server:
On IIS 4.0, ASP.DLL 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, ASP.DLL 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 ASP.DLL to run out-of-process?
Yes. Microsoft has long recommended that, whenever possible, IIS 4.0
should be configured to run ASP.DLL and other components out-of-process.
This not only improves security, but stability as well. There is,
however, a performance penalty associated with running out of process.
I don’t use Active Server Pages. Would disabling the functionality
altogether protect my server?
Yes. In fact, Version 1.0 of the IIS Lockdown Tool disabled ASP by
default. The current version of the Tool, version 2.1, provides a number
of different server roles. Selecting “Static Web Server” will disable
ASP by default.
I’ve deployed the URLScan Tool on my server. Will it protect my
system against this vulnerability?
By default, it would not. However, it would be possible add a rule
that would block chunked encoding requests. Just add 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”).
Microsoft has release an updated version of the URLScan that
implements this rule by default, as well as improving the protection the
tool can provide. The updated tool is available for download at http:
//www.microsoft.com/technet/security/URLScan.asp.
How does the patch eliminate this vulnerability?
The patch eliminates the arithmetic error that causes the vulnerability.
Microsoft-discovered variant of Chunked Encoding buffer overrun
(CVE-CAN-2002-0147)
What’s the scope of this vulnerability?
This vulnerability is identical to the preceding one in scope, effect,
and remediation. There are only two significant differences:
This vulnerability affects additional versions of IIS. Specifically,
it affects IIS 4.0, 5.0 and 5.1.
It cannot be blocked by URLScan.
What causes this vulnerability?
This vulnerability results because of a handling error in the allocation
of buffers for data transfers. Although it involves a similar
functionality as preceding one, and has the same overall effect, there
are nevertheless some important differences between the two
vulnerabilities.
What are the differences between this vulnerability and the preceding
one?
There are two primary differences. First, where IIS 5.1 is not
affected by the preceding one, it is affected by this one. Second,
unlike the preceding vulnerability, this one could not be blocked via
URLScan.
How was this vulnerability found?
Microsoft discovered this vulnerability through code inspection as
part of the investigation of the preceding one.
Buffer Overrun in ASP Server-Side Include Function (CVE-CAN-2002-0149)
What’s the scope of this vulnerability?
This is a buffer overrun vulnerability affecting IIS 4.0, 5.0 and 5.1.
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 and 5.1
Customers who have used the IIS Lockdown Tool to configure their servers
as static web servers are already protected against the vulnerability.
Likewise, the URLScan tool, when deployed with the default ruleset,
would make it difficult to use the vulnerability to gain control of
the server, and likely reduce it to a denial of service attack only.
What causes the vulnerability?
The vulnerability results because of a logic error in a function that
handles server-side file includes for Active Server Pages. The result of
the error is that the function could conclude that it is safe to
store the name of a specified server-side file in a particular buffer,
when in actuality the filename is longer than the buffer
What are server-side file includes?
Frequently, developers need to be able to incorporate a file into a
program – for instance, as a way of reusing existing code. File
includes provide a way to do this. The developer specifies what file
should be included in the program, and at what point, and the contents
of the file are treated as though they were part of the program.
ASP, like most programming languages, supports file includes. In the
case of ASP, the included files come from the web server itself, so
they’re known as server-side file includes. When an ASP script runs,
a pre-processing step handles any file includes, after which point the
ASP ISAPI filter processes the result.
Can a visitor to a web site request a server-side include?
No. After all, a web site visitor should never actually be involved in
the operation of ASP scripts – all processing should occur on the
server. However, it is possible for user actions to have the effect of
causing a file include on the server to happen. This vulnerability
involves the operation of IIS when this is done, and in a particular
way.
What’s wrong with how IIS handles server-side includes?
In some cases, requesting a particular web page will cause it to be
included within an ASP script as part of its processing. Because this
involves putting user input into a buffer, IIS always performs a check
beforehand, designed to make sure the input is valid. Specifically, it
performs an operation on the file name that should only succeed if the
file name is valid.
A security vulnerability results because it’s possible to levy a
request that includes a very long, invalid file name, but do it in a way
that has two effects. First, the ASP ISAPI extension concludes that the
filename needs to be processed as part of an ASP file, and does a
server-side include. Second, the filename evades the safety check. The
result is that the file name – which is longer than the buffer
allocated to hold it – causes a buffer overrun in the ASP file when it
’s processed.
What would the vulnerability 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 could establish a session with an affected web server could
exploit the vulnerability.
If the vulnerability were exploited to cause the IIS server 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 and 5.1, the service would automatically restart itself.
If the vulnerability were exploited to change the operation of the
server software, what would the attacker be able to do?
If exploited in this way, the attacker could gain the same privileges as
discussed above:
On IIS 4.0, the attacker could gain complete control over the server
On IIS 5.0 and 5.1, the attacker could gain the privileges associated
with the Web Application Manager – essentially, those of an
unprivileged user.
Would the IIS Lockdown Tool help protect my server?
The vulnerability could only be exploited if Active Server Pages are
enabled on the server. Version 1.0 of the IIS Lockdown Tool disables ASP
by default. The current version of the Tool, version 2.1, provides a
number of different server roles. Selecting “Static Web Server”
disables ASP by default.
Would the URLScan tool protect my system against this vulnerability?
It wouldn’t offer total protection, but it would significantly reduce
the scope of the vulnerability. By default, URLScan blocks all URLs that
contain non-ASCII data. This would not prevent an attacker from causing
the service to fail – overrunning the buffer with virtually any data
would accomplish that goal. However, it would make it difficult to
exploit the vulnerability to alter the operation of the server software,
because the attacker would need to construct valid executable code
using only ASCII data.
How was this vulnerability found?
Microsoft discovered this vulnerability as part of a security review.
How does the patch eliminate the vulnerability?
The patch correct the truncation error, thereby ensuring that the URLs
under discussion here will not be passed to the function.
Buffer Overrun in HTTP Header Handling (CVE-CAN-2002-0149)
What’s the scope of this vulnerability?
This is a buffer overrun vulnerability affecting IIS 4.0, 5.0 and 5.1.
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 and 5.1.
Customers who have used the IIS Lockdown Tool to configure their servers
as static web servers are already protected against the vulnerability.
Likewise, the URLScan tool, when deployed with the default ruleset,
would prevent this vulnerability from being used to gain control of
the server, and reduce it to a denial of service attack only.
What causes the vulnerability?
The vulnerability results because of an error that occurs when Active
Server Pages parse HTTP header information. An initial check is
performed, with the goal of ensuring that required delimiters are
present in the information and in reasonable locations before moving the
information in a buffer for processing. However, the check can be
spoofed, with a buffer overrun as the result.
What are HTTP headers?
When a client sends a request to a web server, it needs a way to give
the web server specific information about the request. For instance,
it needs to indicate how data in the request has been formatted, what
web browser the client is using, what action the server should perform,
and so on. All of this information is specified via fields in the
request known as HTTP headers.
What’s wrong with the way IIS handles HTTP headers?
When IIS receives an HTTP request, it must parse the headers so it can
interpret them and take the appropriate action. This is done by breaking
the headers into their constituent parts and putting each in a buffer;
IIS determines where each of the parts ends by looking for a delimiting
character.
IIS checks before performing this operation, to make sure that the
delimiting characters are really present, and located at appropriate
places within the request. However, by constructing a request in a
particular way, it’s possible to spoof this check, and make IIS
conclude that the delimiting characters are present when in fact they
aren’t.
Why does this result in a security vulnerability?
The purpose of the check is to ensure that IIS never copies more
information into the buffer than it’s designed to hold. However, by
spoofing the checks, this protection could be bypassed, resulting in a
buffer overrun.
Specifically, suppose an attacker sent a request that contained a
large amount of data within the HTTP header fields. Ordinarily, IIS
would detect that the data didn’t contain the expected delimiters,
and that the fields were therefore too large to fit safely in the
buffers. It would therefore reject the request. However, if the
request was constructed to exploit this vulnerability, IIS would
incorrectly conclude that the request was well-formed, and would copy
the fields into the buffer, thereby overrunning it.
What would the vulnerability 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 could establish a session with an affected web server could
exploit the vulnerability.
If the vulnerability were exploited to cause the IIS server 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 and 5.1, the service would automatically restart itself.
If the vulnerability were exploited to change the operation of the
server software, what would the attacker be able to do?
If exploited in this way, the attacker could gain the same privileges as
discussed above:
On IIS 4.0, the attacker could gain complete control over the server
On IIS 5.0 and 5.1, the attacker could gain the privileges associated
with the Web Application Manager – essentially, those of an
unprivileged user.
Would the IIS Lockdown Tool help protect my server?
The vulnerability could only be exploited if Active Server Pages are
enabled on the server. Version 1.0 of the IIS Lockdown Tool disables ASP
by default. The current version of the Tool, version 2.1, provides a
number of different server roles. Selecting “Static Web Server”
disables ASP by default.
Would the URLScan tool protect my system against this vulnerability?
It wouldn’t offer total protection, but it would significantly reduce
the scope of the vulnerability. By default, URLScan blocks all URLs that
contain non-ASCII data. This would not prevent an attacker from causing
the service to fail – overrunning the buffer with virtually any data
would accomplish that goal. However, it would make it difficult to
exploit the vulnerability to alter the operation of the server software,
because the attacker would need to construct valid executable code
using only ASCII data.
How does the patch eliminate the vulnerability?
The patch corrects the checking mechanism, and ensures that it’s
performed correctly in all cases.
Buffer overrun in HTR ISAPI extension (CVE-CAN-2002-0071)
What’s the scope of this 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 cause it to temporarily stop providing web services or,
in very unusual cases, could gain control of the server.
There are a number of factors that tend to reduce the severity of this
vulnerability:
The most likely effect of exploiting this vulnerability would be to
disrupt service on the web server. While it would be possible to use the
vulnerability to gain control over the server, it would in most cases
require fortuitous circumstances for the attacker.
The component containing the vulnerability is removed by default by
the IIS Lockdown Tool.
The URLScan tool’s default configuration would prevent the
vulnerability from being exploited.
What causes the vulnerability?
The vulnerability results because the ISAPI extension that implements
HTR scripting contains an off-by-one error when calculating the size
of a buffer for storing an input value. If a request for an HTR script
were malformed in a particular way, it would be possible to abuse the
miscalculation and conduct a buffer overrun attack. In the least serious
case, this could result in the failure of the IIS service; in the
most serious case (which would be difficult to exploit), it could
allow code to be run on the server.
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 disable 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’s wrong with the HTR ISAPI extension?
When the HTR ISAPI extension receives a request to run a script, it
calculates the size of the buffer that’s needed to contain the request.
However, it miscalculates this value, with the result that it creates a
buffer one byte smaller than needed. By sending a series of HTR
requests, all malformed in particular ways, it could be possible to
use the vulnerability to overwrite memory on the server.
What would this enable an attacker to do?
An attacker could exploit this vulnerability in either of two ways. By
sending a series of requests that simply overran the buffer with
random data, the attacker could cause the service to fail. However, by
carefully selecting the data, it could be possible – although
operationally difficult – to modify the operation of the IIS service to
perform tasks of the attacker’s choice.
If the attacker used this vulnerability to cause the service to fail,
what would be the result?
If exploited against an IIS 4.0 server, the attack would prevent the
server from handling web requests until the administrator restarted
the IIS service. If exploited against an IIS 5.0 or 5.1 server, the
outage would be only temporary, as the IIS service would automatically
restart itself. In either case, any web sessions that were underway when
the service failed would be terminated.
If the attacker used this vulnerability to modify the operation of the
service, would what be the result?
If exploited in this way, the attacker could gain the same privileges as
discussed above:
On IIS 4.0, the attacker could gain complete control over the server
On IIS 5.0, the attacker could gain the privileges associated with the
Web Application Manager – essentially, those of an unprivileged user.
How difficult would it be to exploit the vulnerability to gain control
over the server?
Like the vulnerability discussed above, this is a heap overrun. However,
this one would be more difficult to exploit. For instance, it would
be more difficult from a technical standpoint to write an exploit tool
that takes advantage of a one-byte heap overrun.
Even if an exploit tool were available, the vulnerability could only
be exploited under certain conditions. In practical terms, most of these
conditions would only be present if the server hadn’t serviced any web
requests since the last time it was booted, and even then the
attacker would need specific information about the software running on
the server. Note, however, that none of these factors would be
impossible to overcome, given the right circumstances.
I’ve run the IIS Lockdown Tool. Am I vulnerable to this issue?
By default, the IIS Lockdown Tool disables support for HTR. The
vulnerability could not be exploited against a server on which HTR
support was disabled.
I have URLScan running. Am I vulnerable to this issue?
URLScan’s default ruleset would prevent this vulnerability from being
exploited, even if the server was otherwise vulnerable. We do, however,
recommend applying the patch on any server on which HTR is enabled,
even if URLScan is protecting it.
I’m running a system that’s susceptible to the vulnerability. What
should I do?
The best course of action is to remove HTR support altogether, by
unmapping the HTR ISAPI extension. (The simplest way to do this is via
the IIS Lockdown Tool). We recommend retaining HTR support only if
there’s a business-critical need for it.
Even after removing HTR, we still recommend applying the patch. First,
it fixes vulnerabilities in addition to this one. Second, applying the
patch will ensure that the server would still be protected even if HTR
support were inadvertently re-enabled at some future point.
How does the patch eliminate the vulnerability?
The patch corrects the miscalculation in the HTR ISAPI extension, and
ensures that it allocates a buffer that matches the size of the incoming
request.
Access violation in URL error handling (CVE-CAN-2002-0072)
What’s the scope of this vulnerability?
This is a denial of service vulnerability affecting IIS 4.0, 5.0 and 5.
1. By exploiting this vulnerability, an attacker could temporarily
prevent a web server from providing web services.
The vulnerability would not allow any data on the system to be
compromised, nor would it enable the attacker to gain any privileges
on the system. Microsoft’s investigations to date suggest that this
vulnerability only occurs in cases where Front Page Server Extensions
(FPSE) or ASP.NET are installed on the system, although it is possible
that it may also occur under other conditions as well.
What causes the vulnerability?
The vulnerability occurs because IIS incorrectly handles the error
condition that results when one of the ISAPI filters installed by
Front Page Server Extensions and ASP.NET receives an URL that exceeds
the maximum allowable length. Although the problem lies within IIS,
and therefore could also occur in cases involving additional ISAPI
filters, Microsoft’s investigations to date have not revealed any
others in which this occurs.
What’s an ISAPI filter?
As discussed above, an ISAPI filter is a .dll installed to extend the
functionality available through a web server. The specific filter at
issue in this case is one installed by FPSE and ASP.NET, although others
could also be involved as well.
What is FPSE?
FrontPage Server Extensions (FPSE) is a set of tools that can be
installed on a web server to allow authorized personnel to manage the
server, add or change content, and perform other tasks.
What is ASP.NET?
ASP.NET is a development platform that allows web applications to be
built easily and rapidly. ASP.NET can be thought of as a superset of ASP
-- existing ASP programs can be ported directly to ASP.NET, but it also
provides new, extended functionality.
What’s wrong with FPSE and ASP.NET?
Nothing. The problem in this case involves how IIS handles a
particular type of error condition that can be generated by ISAPI
filters. It happens that the only ISAPI filters Microsoft has identified
so far that actually generate the error condition are associated with
FPSE and ASP.NET. However, the problem doesn’t lie in the ISAPI filter,
but rather in the way IIS handles the error condition.
What’s the error condition, and why does it cause the IIS service to
fail? The error in this case occurs when either of the ISAPI filters
receive a request containing an URL that exceeds the maximum length.
When this happens, the filter fails the request, and sets the URL to a
null value. The vulnerability results because IIS, before sending the
response back to the requester, tries to use the URL. This causes an
access violation that results in the failure of the IIS service.
What would this enable an attacker to do?
An attacker who exploited this vulnerability would be able to cause
the IIS service to fail. This would have the effect of terminating any
sessions that were in process at the time, and preventing any new ones
until the service was restarted.
How might an attacker exploit the vulnerability?
An attacker could exploit the vulnerability by sending to an affected
server a request that would be processed by either of the ISAPI
filters mentioned above, and including an URL that exceeds the maximum
length for the filter. (Likewise, if there were other ISAPI filters
installed on the system that can generate the same error condition,
the attacker could send a request to one of them).
What would be required to resume normal operation?
On IIS 4.0, the operator would need to restart the service. On IIS 5.0
and 5.1, the service would automatically restart itself.
Could the attacker gain any other privileges on the server via this
vulnerability?
No. This is strictly a denial of service vulnerability; there is no
capability to change content on the server, manage it, or take any other
actions.
I haven’t installed FPSE on my server. Could I be affected by the
vulnerability?
Some of the Server Extensions install as part of IIS 4.0, 5.0 and 5.1 by
default, and others must be installed separately. The ISAPI filter at
issue here installs by default, so a server would be affected unless the
administrator had removed FPSE. (FPSE can be removed via the Add/Remove
Programs applet in Control Panel). Even if FPSE has been removed,
keep in mind that it could be possible for a server to have other
ISAPI filters installed that would generate the error condition that
causes IIS to fail.
I haven't installed ASP.NET on my server. Could I be affected by the
vulnerability?
ASP.NET does not install by default as part of IIS. However, even if
ASP.NET is not installed on the system, FPSE would be, as discussed in
the preceding paragraph.
How does the patch eliminate this vulnerability?
The patch cause IIS to check the URL when processing the error at
issue here, and to not attempt to process it.
Denial of service via FTP status request (CVE-CAN-2002-0073)
What’s the scope of this vulnerability?
This is a denial of service vulnerability affecting IIS 4.0, 5.0 and 5.
1. By exploiting this vulnerability, an attacker could temporarily
prevent a web server from providing web services.
The vulnerability could only be exploited if the web server were also
configured to provide FTP services. IIS 4.0 installs FTP services by
default, but IIS 5.0 and 5.1 do not. The IIS Lockdown Tool disables
FTP support by default. The vulnerability would not allow any data on
the system to be compromised, nor would it enable the attacker to gain
any privileges on the system.
What causes the vulnerability?
The vulnerability results because the FTP implementation in IIS 4.0, 5.0
and 5.1 does not correctly handle a request for the status of the
connection, if the request has been malformed in a particular way.
Receiving such a request would result in the failure of the IIS service.
What is FTP?
File Transfer Protocol (FTP) is an industry standard protocol (specified
in RFC 959) that allows users to post files to or retrieve files from a
server. All versions of IIS include an implementation of the protocol.
What’s wrong with the FTP implementation in IIS 4.0, 5.0 and 5.1?
They contain an error in the way they handle a request for the status of
an ongoing FTP connection. Specifically, including certain characters
in the request creates an error condition, but this fact isn’t
correctly reported back to the software module that relayed the user’
s request. The result is that the calling module uses uninitialized
data, thereby causing an access violation.
What would this enable an attacker to do?
FTP services are provided by the IIS service itself, so an attacker
who exploited this vulnerability would be able to disrupt not only FTP
services but web services as well. This would have the effect of
terminating any sessions that were in effect at the time of the attack.
Who could exploit this vulnerability?
Any user who was able to establish an FTP session with an affected
server could exploit the vulnerability. The status request that contains
the flaw can only be levied as part of an already existing session.
What would be required to resume normal operation?
On an IIS 4.0 server, the operator would need to restart the IIS
service. On IIS 5.0 and 5.1 servers, the service would automatically
restart itself.
What’s the significance of the need for the attacker to be able to
establish a session with the server?
It means that an attacker could not simply conduct a “drive-by” attack
and send data to the server. The FTP service would need to be enabled
and running, and the attacker would either need logon credentials, or
the server would need to be configured to allow anonymous logon.
Does FTP install and run by default?
It is enabled and running by default as part of IIS 4.0, but not as part
of IIS 5.0 or 5.1. It’s also worth noting that the IIS Lockdown Tool
disables FTP by default.
If FTP is running, is anonymous logon enabled by default?
Yes. It’s always a good idea to consider whether you really want to
allow anonymous access to your FTP server, and to disable it if this
isn’t the case.
How does the patch eliminate the vulnerability?
The patch causes the FTP service to correctly handle the command at
issue here.
Cross-site Scripting in IIS Help File search facility, Redirect Response
message, and HTTP Error Page (CVE-CAN-2002-0074, 0075, 0148)
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 opened an HTML
mail or visited a malicious user’s web site – the code could not be “
injected” into an existing session. In one of the two cases here,
even if an attacker did exploit the vulnerability, it would have no
effect on a user running IE. 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 “<” or “>”. A full description of
the characters that should be filtered is available in Knowledge Base
article Q252985.
What’s wrong with IIS?
Three services provided by IIS don’t properly filter their inputs,
and as a result could be used in a cross-site scripting attack. The
services are:
A search facility that allows IIS help files to be searched. The
facility is only provided in IIS 5.0 and 5.1, so only these versions are
affected by the vulnerability.
A message that’s returned when someone requests a web page that’s been
moved to a new location. (Such a message is known as a redirect
response). The versions of this message that are produced by IIS 4.0,
5.0 and 5.1 are affected by the vulnerability. However, a successful
attack could only be carried out via this message if the target of the
attack was running a browser other than Internet Explorer.
Several error messages that are returned when a user's request for a web
page results in an error. The default versions of these messages
produced in IIS 4.0 and 5.0 are affected by the vulnerability.
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.
You said above that one of the vulnerabilities could only be exploited
if the user was using a browser other than IE. Why is this?
In the case of the error message that’s returned when a web page has
been moved, IE doesn’t actually display the text in the error message.
Instead, it processes information elsewhere in the server’s response
and immediately takes the user to the new page. As a result, it’s not
susceptible to the cross-site scripting error. Other browsers may or may
not work similarly, depending on how they implement the handling of
redirect responses.
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 eliminate the vulnerability?
The patch eliminates the vulnerability by ensuring that both of the
services discussed above properly filter their inputs before using them.
Patch availability
Download locations for this patch
Microsoft IIS 4.0:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=37931
Microsoft IIS 5.0:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=37824
Microsoft IIS 5.1:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=37857
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 1 or Service Pack 2.
The IIS 5.1 patch can be installed on systems running Windows XP
Professional Gold.
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 3.
The IIS 5.1 fixes will be included in Windows XP Service Pack 1.
Reboot needed:
IIS 4.0: Yes
IIS 5.0: No
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)
Superseded patches:
IIS 4.0 and 5.0: This patch supersedes the one provided in Microsoft
Security Bulletin MS01-044. (This is the previous cumulative patch for
IIS 4.0 and 5.0, and supersedes additional patches)
IIS 5.1: None
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\Q319733.
To verify the individual files, consult the file manifest in Knowledge
Base article Q319733.
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\SP3\Q319733.
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\SP3\Q319733\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\SP1\Q319733.
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\SP1\Q319733\Filelist.
Caveats:
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
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.
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.
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
All patches available via WindowsUpdate also are available in a
redistributable form from the WindowsUpdate Corporate site.
Other information:
Acknowledgments
Microsoft thanks the following people for reporting this issue to us
and working with us to protect customers:
eEye Digital Security (http://www.eeye.com) for reporting the buffer
overrun in the ASP chunked encoding implementation.
Serge Mister of Entrust, Inc., (http://www.entrust.com) for reporting
the buffer overrun affecting the HTTP header handling.
Dave Aitel of @Stake (http://www.atstake.com) and Peter Grundl of KPMG
for reporting the buffer overrun in the HTR ISAPI extension.
Dave Aitel of @Stake (http://www.atstake.com) the access violation in
URL error handling.
Joe Smith (jsm1th@hotmail.com) and zenomorph ( admin@cgisecurity.com) of
http:// www.cgisecurity.com) for reporting the cross-site scripting
vulnerability in the IIS Help File search facility.
Keigo Yamazaki of the LAC SNS Team (http://www.lac.co.jp/security/)
for reporting the cross-site scripting vulnerability affecting
redirect response messages.
Thor Larholm of Jubii A/S for reporting the cross-site scripting
vulnerability affecting HTTP error pages.
Support:
Microsoft Knowledge Base article Q319733 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 (April 10, 2002): Bulletin Created.
※ 来源:·荔园晨风BBS站 bbs.szu.edu.cn·[FROM: 210.39.3.120]
[回到开始]
[上一篇][下一篇]
荔园在线首页 友情链接：深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店