Microsoft Security Bulletin MS01-044

Technical description:

This patch is a cumulative patch that includes the functionality of all security patches released to date for IIS 5.0, and all patches released for IIS 4.0 since Windows NT® 4.0 Service Pack 5. 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 all previously released security patches, this patch also includes fixes for five newly discovered security vulnerabilities affecting IIS 4.0 and 5.0:

• A denial of service vulnerability that could enable an attacker to cause the IIS 4.0 service to fail, if URL redirection has been enabled. The "Code Red" worm generates traffic that can in some cases exploit this vulnerability, with the result that an IIS 4.0 machine that wasn't susceptible to infection via the worm could nevertheless have its service disrupted by the worm.
• A denial of service vulnerability that could enable an attacker to temporarily disrupt service on an IIS 5.0 web server. WebDAV doesn't correctly handle particular type of very long, invalid request. Such a request would cause the IIS 5.0 service to fail; by default, it would automatically restart.
• A denial of service vulnerability involving the way IIS 5.0 interprets content containing a particular type of invalid MIME header. If an attacker placed content containing such a defect onto a server and then requested it, the IIS 5.0 service would be unable to serve any content until a spurious entry was removed from the File Type table for the site.
• A buffer overrun vulnerability involving the code that performs server-side include (SSI) directives. An attacker who had the ability to place content onto a server could include a malformed SSI directive that, when the content was processed, would result in code of the attacker's choice running in Local System context.
• A privilege elevation vulnerability that results because of a flaw in a table that IIS 5.0 consults when determining whether a process should in-process or out-of-process. IIS 5.0 contains a table that lists the system files that should always run in-process. However, the list provides the files using relative as well as absolute addressing, with the result that any file whose name matched that of a file on the list would run in-process.

In addition, this patch eliminates a side effect of the previous IIS cumulative patch (discussed in the Caveats section of Microsoft Security Bulletin MS01-026) by restoring proper functioning of UPN-style logons via FTP and W3SVC.

Mitigating factors:

URL Redirection denial of service:

• This vulnerability only affects IIS 4.0. IIS 5.0 is not affected.
• The vulnerability only occurs if URL redirection is enabled.
• The vulnerability does not provide any capability to compromise data on the server or gain administrative control over it.

WebDAV request denial of service:

• The vulnerability only affects IIS 5.0. IIS 4.0 is not affected.
• The effect of an attack via this vulnerability would be temporary. The server would automatically resume normal service as soon as the malformed requests stopped arriving.
• The vulnerability does not provide an attacker with any capability to carry out WebDAV requests.
• The vulnerability does not provide any capability to compromise data on the server or gain administrative control over it.

MIME header denial of service:

• The vulnerability only affects IIS 5.0. IIS 4.0 is not affected.
• In order to exploit this vulnerability, the attacker would need to have the ability to install content on the server. However, by default, unprivileged users do not have this capability, and best practices strongly recommend against granting it to untrusted users.

SSI privilege elevation vulnerability:

• In order to exploit this vulnerability, the attacker would need to have the ability to install content on the server. However, by default, unprivileged users do not have this capability, and best practices strongly recommend against granting it to untrusted users.

System file listing privilege elevation vulnerability:

• The vulnerability only affects IIS 5.0. IIS 4.0 is not affected.
• In order to exploit this vulnerability, the attacker would need to have the ability to install content on the server. However, by default, unprivileged users do not have this capability, and best practices strongly recommend against granting it to untrusted users.

Vulnerability identifiers:

• URL redirection denial of service: CAN-2001-0545
• WebDAV denial of service: CAN-2001-0508
• MIME header denial of service: CAN-2001-0544
• SSI privilege elevation: CAN-2001-0506
• System file listing privilege elevation: CAN-2001-0507

Tested Versions:

Microsoft tested IIS 4.0 and IIS 5.0 to assess whether they are affected by this vulnerability. Previous versions are no longer supported and may or may not be affected by this vulnerability.

What is a cumulative patch?
This patch not only addresses several newly-discovered vulnerabilities, but also includes all previously released patches for IIS 4.0 and IIS 5.0.

What previously released patches are bundled within this one?
The IIS 4.0 patch incorporates the functionality of all post-Service Pack 5 patches delivered for IIS 4.0. The IIS 5.0 patch incorporates the functionality of all patches delivered to date for IIS 5.0. A complete listing of the patches that this one supersedes is provided in the section of the bulletin titled "Additional information about this patch".

Are there any security vulnerabilities affecting IIS that are not addressed by this patch?
Yes. As discussed in the Caveats section below, several vulnerabilities known to affect IIS 4.0 require administrative action rather than a patch. In contrast, there are no IIS 5.0 vulnerabilities that require administrative action, so this cumulative patch does address all IIS 5.0 vulnerabilities.

Does the patch include fixes for issues involving Index Server and other products that are typically found on IIS servers?
As a rule, IIS patches do not include fixes for other products, like Index Server, that are typically found on IIS servers. However, we have made an exception in the case of the Index Server vulnerability discussed in Microsoft Security Bulletin MS01-033. We've included it in this patch because of its seriousness with respect to IIS servers.

What machines should this patch be applied to?
At a minimum, it should be applied to web servers. However, it may also need to be applied to other systems as well. For instance, Exchange 2000 uses IIS 5.0 if Outlook Web Access is installed. The best way to tell whether you need the patch is to check the list of services that are running. If IIS 4.0 or 5.0 are running, you should apply the patch.

What are the new security vulnerabilities addressed by the patch? 
There are a grand total of five newly discovered vulnerabilities:

• Three vulnerabilities that could enable an attacker to temporarily disrupt service on an IIS web server. The first affects IIS 4.0 only and is particularly significant because it can be exploited by the "Code Red" worm. The second and third affect IIS 5.0 only.
• Two vulnerabilities that could enable an attacker who already had considerable privileges on a web server to gain even greater privileges. The first of these affects both IIS 4.0 and IIS 5.0; the second affects IIS 5.0 only

What's the scope of the first vulnerability?
The first vulnerability is a denial of service vulnerability. An attacker who exploited this vulnerability could temporarily prevent an IIS server from servicing web requests. The vulnerability is being actively exploited by the "Code Red" worm, and this has been widely, although incorrectly, reported as being due to a flaw in the patch provided in Microsoft Security Bulletin MS01-033. In fact, this is a completely different and previously unknown vulnerability.
The vulnerability only affects IIS 4.0 servers, and even then only when they are operated in a non-default configuration. IIS 5.0 servers are not affected by the vulnerability. The vulnerability does not provide a means by which an attacker could gain any degree of administrative control over the server.

What causes the vulnerability? 
The vulnerability results because the code within IIS 4.0 that performs URL redirection does not correctly handle the case in which a request's actual length is different from that specified in the request. Such a request triggers a chain of events that culminates in an access violation, resulting in the failure of the service.

What is URL redirection? 
When you request a web page, you enter an URL like, for instance, http://www.microsoft.com/technet/security, the web server maps this URL into a request for a specific file on the server, e.g., c:\inetpub\technet\security\default.asp. But it frequently happens that content needs to be moved to a different machine or to a new folder structure. URL redirection allows maintenance activities like this to be transparent to web site visitors.
For instance, in our example, suppose the content on the web site were reorganized, and the web page that used to reside at c:\inetpub\technet\security\default.asp were moved to c:\inetput\abc\xyz\default.asp. Of course, site visitors would be able to view the content by navigating to http://www.microsoft.com/abc/xyz, but the web administrator wouldn't want customers who use the old URL to get a "page not found" error. URL redirection allows the web administrator to redirect the file that's pointed to by http://www.microsoft.com/technet/security, so that visitors will continue to see the right web page.

What's wrong with the way IIS 4.0 performs URL redirection? 
Within a web page request is information that says how long the request is. If that information is incorrect, and the request's actual length is longer, it sets off a complex chain of events that ultimately cause the service to fail.

This sounds like a potential buffer overrun. Is it? 
No. The request does not overrun any buffers. This is an important point, because it means that this issue can only be used to disrupt service - not gain control of the server.

What could an attacker do via this vulnerability? 
An attacker could send such a request to a server in an attempt to prevent the server from performing useful service.

What would be required to put the server back into service? 
The administrator could restore normal service by restarting the IIS 4.0 service.

Why is the Code Red worm implicated in this issue? 
When the worm tries to infect a server, it does so by sending a request that attempts to exploit the vulnerability discussed in Microsoft Security Bulletin MS01-033. However, the request contains invalid length information of exactly the type needed to exploit the newly discovered denial of service vulnerability. As a result, the worm can not only infect some servers through the vulnerability discussed in MS01-033, but also can disrupt service in others through this vulnerability.

I heard that this problem is actually due to a flaw in the patch you delivered in Security Bulletin MS01-033. Is this true? 
No. The patch we provided in MS01-033 was designed to prevent a buffer overrun vulnerability from being exploited, and it does that. The vulnerability here is completely different from that one.

If that's true, then why are only servers that have the MS01-033 patch affected by this vulnerability? 
They aren't. Any IIS 4.0 server that performs URL redirection is affected by this vulnerability, regardless of whether it has the MS01-033 patch installed or not. However, it's understandable why people would mistakenly conclude that there's a problem in the MS01-033 patch.
The Code Red worm infects systems by using the vulnerability discussed in MS01-033 to, in essence, inject modified system software into a server. The modifications needed to infect an IIS 4.0 system are different from -- and incompatible with -- those needed to infect an IIS 5.0 system. The designers of the worm had to choose whether to inject IIS 4.0 or IIS 5.0 code into the servers it attacks, and they chose to inject IIS 5.0 code. As a result, if the worm compromises an IIS 4.0 system, it injects IIS 5.0 code into it, which cannot execute. Instead, the result is that the infection attempt causes the IIS 4.0 service to fail.
This gives rise to a situation where two completely different vulnerabilities cause exactly the same effect. If an IIS 4.0 server doesn't have the MS01-033 patch installed, the worm causes it to fail. However, even if the patch is applied to the server, the worm will still cause the service to fail if URL redirection is enabled -- not because of the vulnerability discussed in MS01-033, but because of the vulnerability here. As a result, an administrator of an IIS 4.0 server that's configured to perform URL redirection could conclude that the MS01-033 patch had failed, when in fact it hadn't.

Is URL redirection enabled by default on IIS 4.0? 
No. The web administrator must enable it.

I have URL redirection enabled. Should I turn it off? 
The best course of action is to apply the patch, as it will allow you to continue to use URL redirection, but without the threat of the vulnerability. However, if you want to turn off URL redirection, here's how:

• In the Internet Service Manager, right-click on the web site.
• Select the Home Directory tab.
• In the section titled "When connecting to this resource, the content should come from:", select anything other than "A redirection to an URL".
• Click OK to accept the changes.

Does this vulnerability affect IIS 5.0? 
No. URL redirection in IIS 5.0 isn't affected by this vulnerability.

What does the patch do? 
The patch allows IIS 4.0 to correctly redirect URLs with conflicting length information.

What's the scope of the second vulnerability?
The second vulnerability is a denial of service vulnerability. An attacker could use this vulnerability to temporarily disrupt web services on an IIS 5.0 server.
The effect of exploiting the vulnerability would be only temporary - by default, IIS 5.0 would automatically restart itself after such an attack. However, any sessions in effect when the attack was carried out would be severed and need to be re-established.

What causes the vulnerability?
The vulnerability results because of the way that WebDAV handles a particular type of very long, invalid request. The net effect is to cause an access violation that results in the failure of the IIS 5.0 process.

What is WebDAV?
To explain what WebDAV is, we first need to discuss HTTP. HTTP, or Hypertext Transfer Protocol, is the industry standard protocol by which web content is communicated. It enables clients to request web content, and enables web servers to either supply the content or tell the client why it was unable to supply it.
WebDAV is an extension to the HTTP specification. The "DAV" in "WebDAV" stands for "distributed authoring and versioning", and it adds a capability for authorized users to remotely add and manage content on a web server. WebDAV is fully supported in Windows 2000 and ships as part of the product.

What's wrong with WebDAV?
WebDAV does not properly handle a particular type of request, specifically, one that's very long and contains a particular type of invalid data. Because of a flaw in WebDAV, processing such a request would culminate in an access violation that would cause the IIS 5.0 process to fail.

This sounds like a potential buffer overrun. Is it? 
No. Although the vulnerability occurs in very long requests, it isn't the length of the request that actually causes the vulnerability. In any event, the request in this case does not overrun any buffers. This is an important point, because it means that this issue can only be used to disrupt service - not gain control of the server.

What would this allow an attacker to do?
An attacker could use this vulnerability to disrupt service on an IIS 5.0 server. Exploiting the vulnerability would cause the IIS 5.0 service to fail, with the result that any ongoing sessions would be lost, and users would be unable to start new sessions. However, the effect wouldn't last long, as IIS 5.0 is configured by default to automatically restart itself.

Who could exploit the vulnerability?
Any user who had connectivity with an affected server could exploit the vulnerability. It would not be necessary for the attacker to authenticate to the machine.

Would this vulnerability enable an attacker take any administrative action on an affected system?
No. The vulnerability would only enable the attacker to disrupt service on the system. There is no capability via this vulnerability to carry out unauthorized WebDAV commands, compromise data on the system or take any kind of administrative action on it.

Is WebDAV installed and running by default?
Yes. WebDAV is installed by default on IIS 5.0 web servers.

Could the vulnerability be exploited accidentally?
No. It's extremely unlikely that any user would accidentally create a WebDAV request with the length and specific malformation involved here.

Does this vulnerability affect IIS 4.0?
No. WebDAV did not ship as part of IIS4.0.

I'm running IIS 4.0. Does this mean that I don't need the patch?
No. The patch addresses all of the vulnerabilities described in this bulletin, one of which does affect IIS 4.0. You should apply the patch if your system is affected by any of the vulnerabilities discussed in the bulletin.

How does the patch eliminate the vulnerability?
The patch ensures that WebDAV requests of the type implicated in the vulnerability are rejected without causing an access violation.

What's the scope of the third vulnerability? 
The third vulnerability is a denial of service vulnerability. An attacker who exploited the vulnerability would be able to disrupt an affected web server.
In order to exploit this vulnerability, the attacker would need the ability to place content onto an affected web server. However, best practices strongly recommend against ever allowing an untrusted user to install content on a web server. The vulnerability affects only IIS 5.0 servers, and would not enable an attacker to gain any privileges on the server.

What causes the vulnerability? 
The vulnerability results because of a flaw involving the way IIS 5.0 handles MIME information when serving content. If the MIME content-type information were malformed in a particular way, the service would fail when trying to process it.

What's MIME? 
MIME stands for Multipurpose Internet Mail Extensions, and is an industry standard protocol for encoding content on the Internet. Although its name suggests that it only involves email, most Internet content - including web content - uses the MIME standard to specify what type of information the content is.

How does content on a web server use MIME? 
When a web server receives a request for some content, it needs to know whether the content consists of text, graphics, music, video data, and so forth. There's a header in each web content file that provides this information. In this case, a security vulnerability results in the case where the information in the header is malformed in a particular way.

What's wrong with the way IIS 5.0 handles MIME information? 
If web content on an IIS 5.0 server contains a certain type of invalid MIME information, it inserts an invalid entry into a system table. This prevents the server from correctly serving any content until the entry is removed.

What could an attacker do via this vulnerability? 
An attacker who was able to put onto a server content containing the malformation at issue here would be able to request that content in order to put the server in a state in which it couldn't serve any content to any visitors.

How would the attacker get the content onto the server? 
He shouldn't be able to. Best practices strongly recommend against ever allowing an untrusted user to put content on a web server. If this recommendation has been followed, an attacker wouldn't be able to exploit the vulnerability.

How could an affect server be put back into service? 
The web server administrator would need to remove the spurious entry in the system table by performing the following steps:

• Open the Internet Services Manager
• Right-click on the virtual directory containing the content
• Select HTTP Headers, then click on File Types
• Search for an entry in the list whose MIME type is empty, and delete it.

What does the patch do? 
The patch causes IIS 5.0 to treat content that contains the malformation at issue here as though it had not specified a MIME type for the content at all. This causes the content, when requested, to be sent assuming that the client application will know how to parse it.

What's the scope of the fourth vulnerability? 
The fourth vulnerability is a buffer overrun vulnerability. An attacker who exploited the vulnerability could gain complete control over an affected server, and take any desired action on it.
However, the vulnerability can only be exploited by code that is running on the server. As a result, the attacker would need to already have the ability to install software on the server in order to exploit the vulnerability. Best practices strongly recommend against ever allowing an untrusted user to install software on a web server.

What causes the vulnerability?
The code that processes server-side include files contains an unchecked buffer. By installing on an affected server a server-side file that contained a malformed server-side include directive, an attacker could cause the buffer to be overflowed the next time the file was requested by a user.

What are server-side files?
Some web pages, such as static HTML files, are processed entirely by the browser. When such a web page is requested, the web server's role is simply to find the appropriate file and send it to the client, which performs all the work. Such files are known as "client-side" files.
In contrast, many advanced web technologies require that the server perform some processing before sending a web page to the browser. For instance, an Active Server Page is essentially a program that, when requested, runs on the server and generates an HTML file that's then sent to the browser. Files such as these are known as "server-side" files. In the case of this vulnerability, the problem lies in how a particular type of file associated with server-side files - known as a server-side include file - is handled.

What are server-side include files?
Server-side includes (SSI) allow web developers to reduce the work required to build server-side files. By including an SSI directive in a server-side file, a web developer can cause the contents of one file (known as an SSI file) to be incorporated into another file, after which point the combined file is processed.
For instance, suppose that every web page on a particular site needs to carry the company's copyright notice. Rather than adding code to every server-side file to display the notice, a developer might build an SSI file containing the HTML code to display the notice, and then add a SSI directive to every web file on the server, instructing the file to incorporate the copyright file. This would save coding, and allow the developer to change the copyright notice on every web page simply by changing it in the SSI file.

What's wrong with the way SSI files are handled?
IIS 4.0 and 5.0 contain an unchecked buffer in the code that processes SSI directives. If a server-side file were coded to contain a specially malformed SSI directive, it would cause the buffer to be overrun when the file was requested.
As is usually the case with buffer overruns, either of two effects would result. If the buffer were overrun with random data, it would cause the affected code - in this case, the IIS process - to fail. If it were overrun by carefully selected data, it could have the effect of modifying the code that contains the unchecked buffer. For the remainder of the discussion, we'll focus on the latter case, since it's by far the most serious.

What would this enable an attacker to do?
An attacker who could exploit the vulnerability would be able to change the IIS process while it was running, in order to make it take some new action of the attacker's choice.

What security context would the attacker's code run in?
The code that contains the unchecked buffer runs in the Local System context, so the attacker's code would as well. The Local System context is the highest security context on the system, so exploiting this vulnerability would give the attacker complete control over the machine, and enable him to change web content, reconfigure the system, reformat the hard drive, or take virtually any other action.

How could an attacker exploit the vulnerability?
In order to exploit the vulnerability, the attacker would need the ability to create a server-side file and install it on an affected server. Once this was done, any request for the file - whether levied by the attacker or another user - would trigger the buffer overrun.

But this assumes that the attacker could install a file on the server. How likely is it that he could do this?
Under default conditions, untrusted users can't do this. The default permissions for both IIS 4.0 and 5.0 deny web site visitors the ability to upload files to the server, and this vulnerability doesn't provide any way to circumvent this restriction. The attacker would need to have already compromised the web server to some degree - for instance, through a misconfiguration on the server - before being able to use this vulnerability.
Nevertheless, the vulnerability shouldn't be discounted. If an attacker managed to gain some degree of access to a server, this vulnerability could enable him to significantly broaden the scope of the compromise.

How does the patch eliminate this vulnerability?
The patch eliminates the vulnerability by instituting proper input checks in the affected code.

What's the scope of the fifth vulnerability? 
The fifth vulnerability is a privilege elevation vulnerability. An attacker who already had the ability to load a program of his choice onto an IIS 5.0 web server and run it could use this vulnerability to make the program run in the security context of the operating system itself. This would enable the attacker's program to take virtually any action on the server.
The requirement that the attacker already be able to load a program onto the web server and execute it would significantly increase the difficulty of exploiting this vulnerability. If best practices have been followed, only trusted users will be able to do this, and only after their code has been inspected.

What causes the vulnerability?
IIS 5.0 keeps a list of executables that, by default, run "in process". The vulnerability results because the list that specifies the names does so using relative paths as well as absolute paths. This use of relative paths means that if an executable having the same name as one on the list were uploaded to any folder on the server and executed, it would run in process. Once this occurred, the executable could, by definition, gain system privileges.

What do you mean by running "in process"?
IIS can be configured so that, when a program is run on the server, it either runs as part of the IIS process or as a separate process. The former case is known as running "in process", and the latter case is known as running "out of process".
Running in process provides much better performance than running out of process, but this comes at a potential cost to security. By design, a program running in process can always gain the privileges of the parent process, which in this case is IIS itself. In IIS 4.0, all programs run by default in process, and as a result the administrator must ensure that only trusted code is loaded on the server. In IIS 5.0, programs run out of process by default, with a few exceptions. The vulnerability results because of the way these exceptions are handled.

What are the exceptions, and what's wrong with the way they're handled?
IIS 5.0 keeps a list of programs that are trusted and allowed to run in process regardless of the default settings on the server. The programs on this list are all ones that ship with the product. The problem lies in how the list specifies the programs.

What's wrong with how the exceptions are specified?
A security vulnerability results because the files on the exception list are specified using both absolute path names (e.g., c:\folder1\folder2\program.dll) and relative path names (e.g., program.dll). As a result, if a program having the same name as one of the exceptions were loaded into any folder on the server and executed, it would run in process and would then be capable of gaining system-level privileges.

What could this enable an attacker to do?
If an attacker were able to load a program of his choice on an IIS 5.0 server and execute it, the code would be able to gain system privileges. This would give the attacker complete control of the server. He could do anything he wished, from modifying web pages, to reconfiguring the server, to reformatting the hard drive.

But this assumes that the attacker could load and execute a program on the server. How likely is it that he could do this?
Under default conditions, untrusted users can't load and execute programs on the server. As a result, it's likely that before an attacker could exploit this vulnerability, either of two things would need to happen: either the administrator would need to misconfigure the server, or the attacker would need to gain authoring privileges on the server through some other means.

Does this vulnerability affect IIS 4.0?
It doesn't, but it's important to be precise about why. Recall two points from the discussion above:

• The mechanism by which some programs run in process and some run out of process was introduced in IIS 5.0
• In IIS 4.0 all programs run in process by default

The vulnerability results because of a flaw in the newly introduced mechanism that didn't exist in IIS 4.0. However, even though this is the case, it's also true that if an attacker were able to load a program onto an IIS 4.0 server and run it, the code would, by default, run in process and the attacker would therefore be able to gain privileges on it. For this reason, it's extremely important that IIS 4.0 server administrators only allow trusted code to be loaded onto the server.

I'm running IIS 4.0. Does this mean that I don't need the patch?
No. The patch addresses all of the vulnerabilities described in this bulletin, one of which does affect IIS 4.0. You should apply the patch if your system is affected by any of the vulnerabilities discussed in the bulletin.

How does the patch eliminate the vulnerability?
The patch causes the list of programs that should run in-process to be specified only using absolute addressing.

Download locations for this patch

• Microsoft IIS 4.0:

  http://www.microsoft.com/downloads/details.aspx?FamilyId=7DD8F695-FA97-4378-B57B-7BCCF3533BE3&displaylang=en

• Microsoft IIS 5.0:

  http://www.microsoft.com/downloads/details.aspx?FamilyId=F74552AC-4313-4F93-9412-539DCA0753EB&displaylang=en