Microsoft Security Bulletin MS01-026

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.

The patch also eliminates three newly discovered vulnerabilities:

• A vulnerability that could enable an attacker to run operating system commands on an affected server. When IIS receives a user request to run a script or other server-side program, it performs a decoding pass to render the request in a canonical form, then performs security checks on the decoded request. A vulnerability results because a second, superfluous decoding pass is performed after the security checks are completed. If an attacker submitted a specially constructed request, it could be possible for the request to pass the security checks, but then be mapped via the second decoding pass into one that should have been blocked -- specifically, it could enable the request to execute operating system commands or programs outside the virtual folder structure. These would be executed in the security context of the IUSR_machinename account which, by virtue of its membership in the Everyone group, would grant the attacker capabilities similar to those of a non-administrative user interactively logged on at the console.
• A vulnerability that could enable denial of service attacks against the FTP service. A function that processes wildcard sequences in FTP commands doesn't always allocate sufficient memory when performing pattern matching. Under unusual circumstances, it could be possible for an attacker to levy an FTP command containing a wildcard sequence that, when expanded, would overrun the allocated memory and cause an access violation. This would cause the IIS service (which provides both the web and FTP functionality) to fail. As a result, all web or FTP sessions in progress at the time would be severed, and no new sessions could be established until the IIS service was restarted. In IIS 5.0, the service would restart automatically. In IIS 4.0, operator intervention would be required to restart the service.
• A vulnerability that could make it easier for an attacker to find Guest accounts that had been inadvertently exposed via FTP. By design, if a user wishes to log onto an FTP server using a domain user account, rather than a local one, he should be required to precede it with the name of the domain. However, if an attacker preceded an account name with a particular set of characters, the FTP service would search the domain, and all trusted domains, for the user account. The account would need to be enabled, and the attacker would still need to know the correct password in order to log into the account. For all practical purposes, this would limit the attacker to attacking the Guest account, as it is the only account with both a well-known account name and a well-known default password.

The patch also corrects errors in three previous patches:

• The patch originally provided in Microsoft Security Bulletin MS00-060 successfully eliminated the vulnerability at issue there, but created an opportunity to cause the server to expend an inordinate amount of time processing a particular type of invalid request.
• The patches originally provided in Microsoft Security Bulletins MS01-014 and MS01-016 (which superseded MS01-014) successfully eliminated the vulnerabilities at issue there, but created a potential denial of service condition via a memory leak.

Mitigating factors:

IIS vulnerability:

• The vulnerability does not provide a way for the attacker to learn the folder structure on the server. As a result, if the operating system were installed on a separate drive from the web root or in non-standard folders, it could prevent an attacker from locating programs of interest.
• The vulnerability does not provide administrative access to the server. If the recommendations in the IIS 4.0 and IIS 5.0 security checklists have been followed, sensitive programs will have been moved to folders that can only be accessed by the Administrator, and non-administrative access to server resources will be have been severely restricted.

FTP denial of service vulnerability:

• The attacker would require the ability to start an FTP session in order to exploit the vulnerability.

FTP user account vulnerability:

• The vulnerability could only be exploited if the FTP server was a domain member. However, this is usually not appropriate for Internet-connected FTP servers.
• The vulnerability could only be exploited if the Guest account on the local machine was disabled, but the Guest account on a trusted domain was enabled. By default, the Guest account is disabled in both Windows NT 4.0 and Windows 2000.

Vulnerability identifiers:

• IIS vulnerability: CAN-2001-0333
• FTP denial of service vulnerability: CAN-2001-0334
• FTP user account vulnerability: CAN-2001-0335
• Denial of service vulnerability in MS00-060 patch: CAN-2001-0336
• Memory leak in MS01-014 and MS01-016 patches: CAN-2001-0337

Tested Versions:

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

The Technical Details section says this is a cumulative patch. What does that mean?
Normally, a security patch addresses only newly discovered security vulnerabilities. However, this patch not only addresses three newly-discovered vulnerabilities, but also includes virtually all previously released patches for IIS 4.0 and IIS 5.0.

Why are you releasing a cumulative patch? 
Microsoft understands that security patches only protect customers if they're installed on the machines that need them, and we want to make this as easy as possible. As part of an ongoing effort to simplify the management of security patches, we will be deploying cumulative patches whenever feasible.

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 4.0 that are not addressed by this patch? 
Yes. Two previously released bulletins discuss vulnerabilities affecting IIS 4.0 that cannot be eliminated via code changes. Instead, they require an administrative action of some kind. Even if this cumulative patch has been installed, administrators still need to ensure that they've taken the administrative actions discussed in the following bulletins:

• Microsoft Security Bulletin MS99-025 (which discusses the same issue as Microsoft Security Bulletin MS98-004). The administrative action in this case is to either uninstall or reconfigure the Microsoft Data Access Components, which are by accessible by default via web services.
• Microsoft Security Bulletin MS99-013. The administrative action in this case is to ensure that sample files (which are not installed in IIS by default) are not present on production machines.

Are there any security vulnerabilities affecting IIS 5.0 that are not addressed by this patch? 
No. All security vulnerabilities identified to date in IIS 5.0 are addressed by code changes rather than administrative action, and the patch includes all of them.

If I install this patch on my web server, does this means it's secure?
No. Staying current on security patches is an important step in keeping your server secure, but it's not sufficient by itself.

• The patch does not incorporate any previously released operating system patches. Even after applying this patch, you need to ensure that you've installed all of the appropriate patches for Windows NT 4.0 and Windows 2000.
• The patch does not incorporate previously released patches for non-IIS products, even though some of these are commonly installed on web servers. In particular, this patch does not include any previously released patches for Front Page Server Extensions or Index Server. A listing of the patches for these two products is provided below in the listing of caveats in "Additional information about this patch".
• Even after applying all needed patches, a web server still needs to be appropriately configured for its role - that is, it needs to be configured to provide the services you want it to provide, and no others. The Microsoft TechNet Security web site contains information to help you do this, in the form of security tools and checklists, white papers, and other security resources. In addition, Microsoft Press publishes a number of books discussing IIS, Windows 2000 Security, and security for web-based applications.

What are the new security vulnerabilities addressed by the patch?
The newly discovered vulnerabilities are:

• A vulnerability that could enable an attacker to execute operating system commands on a web server.
• A vulnerability that could enable an attacker to prevent an FTP server from performing useful work.
• A vulnerability could make it easier for an attacker to gain access to a poorly configured network via FTP.

In addition, the patch provides new fixes for the issues discussed in Microsoft Security Bulletin MS00-060, MS01-014 and MS01-016.

What's the scope of the first vulnerability?
This vulnerability would enable a malicious user to execute operating system commands on an affected web server. This would give him the ability to modify web pages, add, change or delete files, reformat the hard drive, or take other actions -- including uploading code of his choice to the server and executing it.
Best practices, if followed, could make it difficult or impossible for an attacker to exploit the vulnerability. Even if an attacker did exploit it successfully, the vulnerability would not grant him administrative control over the server -- instead, it would grant him privileges normally reserved for a user who could log onto the server interactively. Nevertheless, even these privileges would enable a malicious user to cause widespread damage, and could give him a point from which to launch additional attacks in the hope of gaining additional privileges.

What causes the vulnerability? 
The vulnerability results because of an error in the functionality that processes requests to run programs housed on the server. A superfluous decoding operation could give an attacker an opportunity to bypass security checks and escape the server's virtual folder structure, thereby enabling him to run operating system commands on the server.

When you say the problem involves how IIS handles requests to run programs on the server, what do you mean?
Web sites frequently host programs that can be run by visitors. In some cases, visitors to the site run such programs directly, but more often the programs are invoked by web pages on behalf of visitors. A security vulnerability occurs because of the way IIS processes requests to run such programs. Specifically, IIS performs an additional, unneeded decoding operation when processing these requests.

What do you mean by a decoding operation? 
Sometimes, requests to a web server need to include characters like punctuation marks, spaces, tabs, and so forth. The use of such characters complicates the levying of a request, because characters like these can have special meanings. For instance, depending on the context, the space character can be part of a parameter or can be a separator between parameters. There has to be a way to indicate unambiguously how such a character is being used. This is typically accomplished by "escaping" special characters when they occur within a parameter. An escaped character is specified in hexadecimal -- for instance, the escaped version of a space character is "%20".
When IIS receives such a request, it needs to render it into a standardized form that doesn't contain escaped or other special characters. It therefore performs a decoding operation that, among other things, "unescapes" any escaped characters. Once the decoding operation has been completed, IIS performs security checks against the decoded request.

What's wrong with the decoding operation? 
There's nothing wrong with the decoding operation per se. The vulnerability results because, through an implementation flaw, the decoding operation is performed a second time, after the security checks on the request have been completed.

Why does this cause a security vulnerability?
It could be possible for a request to be approved by the security checks and then be transformed by the superfluous decoding operation into one that should have been blocked. Specifically, it could be possible to bypass the checks that are designed to prevent a request from referencing a program outside of the web site's virtual folder structure.

What's a virtual folder structure? 
A virtual folder structure is the set of folders that appear to exist on a web site. The important word here is "appear". Regardless of whether a web site is created through the combined efforts of many computers or is one of several sites hosted by a single computer, it always gives the appearance that it's a single computer that contains nothing but web content. The set of folders on the fictionalized computer is known as the virtual folder structure.
Exposing a virtual folder structure, rather than the actual folder structure on the server, serves two purposes. First, it's essential in supporting the idealized notion of a web site as a single computer. Second, it hides operating system and other commands that users should not be able to access. The risk posed by this vulnerability is that it provides a way to escape the virtual folder structure and access operating system commands or other programs on the server that lie outside the virtual folders.

What would this vulnerability enable an attacker to do?
By creating a specially formed request and sending it to an affected server, an attacker could cause IIS to run a program outside of the virtual folder structure, such as an operating system command.

If a malicious user did exploit the vulnerability, in what security context would the operating system commands be executed? 
The operating system commands would be executed in the security context under which the user authenticated to the web site. In the vast majority of cases, this would mean that the commands would be executed under the built-in IUSR_machinename account. This is the account that performs web actions on behalf of anonymous visitors to the site.
It's rare for a public web site to allow users to authenticate to user accounts other than IUSR_machinename, but if this were the case, the operating system commands would execute with the privileges of the account to which the user had authenticated. For instance, suppose the webmaster created a user account named Joe, and the malicious user authenticated to the web site as Joe. If he then exploited the vulnerability, the operating system commands would execute in the security context of the Joe account.

What privileges does the IUSR_machinename account have?
The IUSR_machinename account has relatively few privileges under IIS - it only has those that are acceptable for general use by visitors to the site. However, the danger lies in the fact that the vulnerability enables the malicious user to escape from the constraints enforced by IIS, and work directly at the operating system level.
In essence, gaining the ability to execute operating system commands in the security context of the IUSR_machinename account would grant the same privileges to the malicious user as those normally available to users who can log onto a machine locally. By default, this would allow him to read and write files, reformat the hard drive, change web pages, and take other actions as well. In addition, it would allow him to upload additional software to the machine and execute it - so, having gained the ability to run code as IUSR_machinename, he could try to leverage this access to gain additional privileges.

Would this vulnerability give a malicious user complete control over the machine? 
No. The IUSR_machinename account doesn't have access to many important files and tools. For example, backup copies of the system files in the winnt\repair folder, including the Security Account Manager file (sam._) are only accessible to administrators, and could not be obtained via this vulnerability. Likewise, tools like the Local Users and Groups snap-in require administrative privileges to execute. However, as we discussed above, even the ability to run operating system commands under the IUSR_machinename account would give a malicious user an opportunity to cause significant damage, and could potentially give him a beachhead from which to conduct additional attacks and try to obtain additional privileges.

How difficult would it be to exploit this vulnerability?
It would depend on two factors that could vary significantly from site to site. First, the attacker would need to be able to locate the operating system commands and programs he wanted to run via the vulnerability. The vulnerability doesn't provide any way for the attacker to learn what the actual folder structure on the server is. Of course, the default folder structure is well-known, so it would be relatively easy for an attacker to find programs in such a case. However, even relatively simple steps, such as installing the web server on a different drive from the operating system or installing the operating system files in a non-standard location, could make it difficult or impossible for the attacker to find programs of interest.
Second, even if the attack could find the files, he would need permission to execute them. If the administrator had followed the recommendations in the IIS 4.0 and 5.0 security checklists and had moved critical operating system commands to a separate directory and made them accessible only to the administrator, the attacker wouldn't be able to execute them.

How does the patch eliminate this vulnerability? 
The patch eliminates the vulnerability by causing the security checks to be made only after all translation steps are complete.

What's the scope of the second vulnerability?
The second vulnerability is a denial of service vulnerability. By entering a particular type of invalid command within an FTP session, an attacker could cause all web services on the server to fail.
There is no capability to add, change or delete data on the server via this vulnerability, or to usurp any administrative privileges. On a server running IIS 5.0, the service would restart itself automatically; on an IIS 4.0 system, the operator would need to restart the service to restore normal operation.

What causes the vulnerability? 
The problem results because of a flaw in a pattern-matching function that is used by at least one FTP command. Depending on the wildcard sequence that's entered and the specific configuration of the server's file system, it would be possible for the resulting pattern to exceed the available memory and trigger an access violation. This in turn would cause the IIS service to fail.

What do you mean by a pattern-matching function?
By "pattern-matching function", we mean the function that provides support for wildcarding in filenames. Like many operating systems and applications, FTP enables the user to use wildcard characters like asterisks and question marks to extend commands to operate on groups of files rather than single files. A single pattern-matching function is used by all commands to expand the wildcards and match the result patterns to the filenames they match. The vulnerability results because of a flaw in this function.

What's wrong with the pattern-matching function? 
The function allocates memory in which to expand the wildcard sequences and identify matches. However, in some cases, it doesn't allocate sufficient memory, and the resulting set of matches can overflow the storage, causing an access violation. This, in turn, causes the IIS service to fail.
It's worth noting that the flaw doesn't manifest itself in all cases. In the vast majority of cases, the function allocates memory correctly. It only allocates insufficient memory under certain conditions. Even when insufficient memory is allocated, the access violation only occurs when particular wildcard sequences are used.

This sounds similar to a buffer overrun vulnerability. Is it one?
Although it involves data overflowing a storage area in memory, this isn't a buffer overrun. It could not be used to run code or take any other actions besides disrupting IIS services.

What would happen if the access violation occurred? 
The access violation would cause the IIS service to fail. This would cause all FTP sessions to be lost, and would prevent new ones from being established until the service was restarted. If the server also provided web services, these would be disrupted as well. In the case of an IIS 5.0 server, service would automatically resume almost immediately; in the case of an IIS 4.0 server, the administrator would need to restart the IIS service to resume normal FTP and web services.

How could an attacker exploit this vulnerability?
An attacker could use this vulnerability to deliberately interfere with the operation of an FTP server. By starting an FTP session with an affected server, and then entering a command that contained the correct wildcard sequence, the attacker could force the IIS service to fail.

Are there any impediments that would make it difficult to exploit this vulnerability? 
Yes. The attacker could only exploit the vulnerability if he could start an FTP session on an affected server. Many FTP servers provide anonymous access, but the administrator could restrict this access if appropriate. Of course, if the least privilege principle of security administration has been followed, the list of people who can access the server will be a small as possible.

What does the patch do? 
The patch eliminates the vulnerability by causing the pattern-matching function at issue here to correctly allocate memory. This prevents the access violation from occurring.

What's the scope of the third vulnerability?
The third vulnerability is an information disclosure vulnerability. It would not give an attacker a way to do anything he couldn't already do, but it would make it easier for him to exploit a misconfigured network. In the worst case, the vulnerability could assist an attacker in gaining access to a domain account.
The vulnerability has a number of significant restrictions:

• The attacker would need to know the correct password for the account. The most likely account to be affected -- the Guest account - is disabled by default.
• The vulnerability could only be exploited if the system administrator had made the FTP server a domain member. However, this is rarely appropriate for an FTP server.

What causes the vulnerability?
The vulnerability results because, if a userid is specified in a particular way when a user logs onto an affected FTP server, the system will automatically search all trusted domains for a userid that matches it. If the userid is found and the correct password is provided, the system will allow the user to log into it normally.

What do you mean by a trusted domain? 
Domains in Windows NT and Windows 2000 can enter into trust relationships, in order to allow users in one domain to access resources in another. For instance, the administrator of Domain A might agree to trust Domain B, thereby allowing users in Domain B to access and use servers, files, and other resources in Domain A. This is referred to as a trust relationship because Domain A (the trusting domain) is agreeing to trust Domain B (the trusted domain) when it vouches for the identities of its users.

What does this have to do with FTP?
Domain trusts matter to FTP because they affect who can log onto an FTP server. A user can always log onto an FTP server via a user account that's local to the server itself. However, if the server is a domain member, a user can also log onto the server via one of the domain user accounts. Finally, if the server is a member of a domain that trusts another domain, a user can log onto the server via one of the trusted domain's user accounts. Of course, the user would need to know the password for any user account he wanted to log into.

How does the server know whether to log the user into a local user account or a domain one? 
It depends on how the user enters the account name. If he entered only the account name by itself - for instance, "John" - the server would attempt to log him onto the server using a local account. If he wanted to log into a domain account, the user would need to preface the user account name with the domain name - for instance, DomainA\John.

Is there any way for a user to determine what accounts are available?
By design, there should be no way for a user to determine which accounts exist, either on the local machine, in the domain the machine belongs to, or in any trusted domains. The user should need to already know the user account name and the domain name in order to begin the login process. This vulnerability doesn't remove this safeguard, but it does weaken it.

What's the vulnerability? 
If a user enters a user account name that's prefaced with a particular set of characters, the FTP service won't require that the user provide the name of the domain the account belongs to. Instead, it will search the server's domain and all of the domains it trusts for a user account name that matches the one the user entered. If one is found, and the user enters the right password for that account, it will log him onto the server.

What's so bad about that? The user did know the password, after all.
The user shouldn't be able to log into a domain user account without knowing and specifying the domain name. Of course, an attacker could always conduct a brute-force attack and simply try every possible domain name and user account name. However, this vulnerability clearly would make an attack much easier.

But the user would still need to know or guess the name of a valid domain user account, right? 
That's correct, and as a result, it's likely that this vulnerability would only be useful in a few scenarios. In particular, it would be helpful in mounting an attack involving the Guest account, because that account has both a well-known account name and a well-known password. If enabled, the Guest account's default password is blank.
To see why this would provide an advantage to an attacker, suppose an FTP server was a member of a domain that trusted 20 other domains, and suppose the Guest account in Domain15 had inadvertently been enabled. If an attacker entered "Guest" as the account name (prefaced, of course, by the correct characters), this vulnerability would cause the FTP service to search all of the trusted domains, and then log the user into Domain15\Guest. By entering a blank password, the attacker would gain access to the Domain15\Guest account.

But suppose the Guest account on the local machine was disabled. What then?
It wouldn't prevent the attacker from logging into the Domain15\Guest. However, there is one aspect of this issue that's worth considering. If the Guest account on the local machine had been enabled, the vulnerability could not be exploited, because the FTP service would try to log the attacker into the local Guest account.

But if I enable the local Guest account, I would still be giving untrusted users access to my server, wouldn't I? 
Actually, you wouldn't. The FTP service will not allow logins to the local Guest account, even when it's enabled. In other words, if you enabled the local Guest account, it would prevent an attacker from exploiting this vulnerability, but still wouldn't let him log into the local Guest account. Of course, the best way to prevent the vulnerability would be to apply the patch.

What could an attacker do if he exploited this vulnerability and gained access to a domain Guest account?
It depends on the privileges the account has been given on the domain. In the example above, the attacker would be able to do anything the Domain15\Guest account was allowed to do. Typically, the Guest account has few privileges, but it is a member of the Everyone group and as a result would be able to view, add or change certain files.

Suppose the Domain15\Guest account had been configured to have a non-blank password. What then? 
The attacker couldn't log on unless he knew the password. Nothing in this vulnerability allows the attacker to learn the password for the account. Indeed, that's why we've focused the discussion on the Guest account - it's one of the few that, if enabled, have a well-known default password.

How likely is it that an FTP server would be affected by this vulnerability?
A properly configured server would be unlikely to be affected by the vulnerability.

• It's rarely appropriate to have an FTP server be a domain member. FTP servers are usually deployed in exposed locations, so it's usually best to configure them as stand-alone machines.
• The number of trusted domains in a network should be kept as small as possible. The example we gave above, in which one domain trusts 20 others, is an example of a poorly configured architecture.
• The Guest account is disabled by default. Unless the administrator of one of the trusted domains has deliberately enabled it, users cannot log onto it.

What does the patch do? 
The patch returns the FTP service to its by-design operation, and causes it to only log a user into a domain account if the domain name is correctly specified.

Why is a new fix required for the issues discussed in the Microsoft Security Bulletins MS00-060, MS01-014 and MS01-016?
The patches provided in these bulletins do eliminate the vulnerabilities, but they contain errors that in some cases could open the server to a denial of service attack.

What's wrong with the original patch for the vulnerability provided in Microsoft Security Bulletin MS00-060?
The patch provided in Microsoft Security Bulletin MS00-060 prevents a cross-site scripting vulnerability by searching for any character sequences that might indicate that HTML code had been included in a request to the server, and replacing them with innocuous text. However, it's possible to abuse the algorithm that performs the search, and cause it to temporarily consume excessive resources on the server. This would prevent the server from responding to other requests in a timely manner.

What's wrong the original patches for the vulnerabilities provided in Microsoft Security Bulletin MS01-014 and MS01-016? 
The patches provided in Microsoft Security Bulletins MS01-014 and MS01-016 eliminate the vulnerabilities as intended, but introduce a memory leak condition that could enable an attacker to gradually deplete the available memory on the server to the point where it could become unresponsive.

What does the new patch do?
The new patch corrects the error in the MS00-060 patch by simply returning an error rather than trying to correct the input. This is an appropriate response, as the input is invalid. It corrects the error in the MS01-014 and MS01-016 patches by eliminating the memory leak.

Download locations for this patch

• Microsoft IIS 4.0:

  http://www.microsoft.com/downloads/details.aspx?FamilyId=8A13DE26-62A1-4306-9C99-C5EB6938A5A0&displaylang=en

• Microsoft IIS 5.0:

  http://www.microsoft.com/downloads/details.aspx?FamilyId=00E2349B-A200-4DCF-A78E-5532BC225AFD&displaylang=en

  Note: This patch has been superseded by the one provided in Microsoft Security Bulletin MS01-044.