• Article

Security Bulletin

Microsoft Security Bulletin MS01-033 - Critical

Unchecked Buffer in Index Server ISAPI Extension Could Enable Web Server Compromise

Published: June 18, 2001 | Updated: November 04, 2003

Version: 1.6

Originally posted: June 18, 2001
Updated: November 04, 2003

Summary

Who should read this bulletin:
System administrators of web servers using Microsoft® Windows NT® 4.0 or Windows® 2000.

Impact of vulnerability:
Run code of attacker's choice.

Recommendation:
Microsoft strongly urges all web server administrators to apply the patch immediately.

Affected Software:

  • Microsoft Index Server 2.0

  • Indexing Service in Windows 2000

    Note: Indexing Service in versions of Windows XP prior to Release Candidate 1 is also affected by the vulnerability. As discussed in the FAQ, Microsoft is working directly with the small number of customers who are using a pre-RC1 beta version in production environments to provide remediation for them.

General Information

Technical details

Technical description:

As part of its installation process, IIS installs several ISAPI extensions -- .dlls that provide extended functionality. Among these is idq.dll, which is a component of Index Server (known in Windows 2000 as Indexing Service) and provides support for administrative scripts (.ida files) and Internet Data Queries (.idq files).

A security vulnerability results because idq.dll contains an unchecked buffer in a section of code that handles input URLs. An attacker who could establish a web session with a server on which idq.dll is installed could conduct a buffer overrun attack and execute code on the web server. Idq.dll runs in the System context, so exploiting the vulnerability would give the attacker complete control of the server and allow him to take any desired action on it.

The buffer overrun occurs before any indexing functionality is requested. As a result, even though idq.dll is a component of Index Server/Indexing Service, the service would not need to be running in order for an attacker to exploit the vulnerability. As long as the script mapping for .idq or .ida files were present, and the attacker were able to establish a web session, he could exploit the vulnerability.

Clearly, this is a serious vulnerability, and Microsoft urges all customers to take action immediately. Customers who cannot install the patch can protect their systems by removing the script mappings for .idq and .ida files via the Internet Services Manager in IIS. However, as discussed in detail in the FAQ, it is possible for these mappings to be automatically reinstated if additional system components are added or removed. Because of this, Microsoft recommends that all customers using IIS install the patch, even if the script mappings have been removed.

Mitigating factors:

  • The vulnerability can only be exploited if a web session can be established with an affected server. Customers who have installed Index Server or Index Services but not IIS would not be at risk. This is the default case for Windows 2000 Professional.
  • The vulnerability cannot be exploited if the script mappings for Internet Data Administration (.ida) and Internet Data Query (.idq) files are not present. The procedure for removing the mappings is discussed in the IIS 4.0 and IIS 5.0 Security checklists, and can be automatically removed via the Windows 2000 Internet Server Security Tool. Customers should be aware, however, that subsequently adding or removing system components can cause the mapping to be reinstated, as discussed in the FAQ.
  • An attacker's ability to extend control from a compromised web server to other machines would depend heavily on the specific configuration of the network. Best practices recommend that the network architecture account for the inherent high-risk that machines in an uncontrolled environment, like the Internet, face by minimizing overall exposure though measures like DMZ's, operating with minimal services and isolating contact with internal networks. Steps like this can limit overall exposure and impede an attacker's ability to broaden the scope of a possible compromise.

Vulnerability identifier: CAN-2001-0500

Tested Versions:

Microsoft tested Index Server 2.0 and Index Service in Windows 2000 and Windows XP to assess whether they are affected by these vulnerabilities. Previous versions are no longer supported, and may or may not be affected by these vulnerabilities.

Frequently asked questions

What's the scope of the vulnerability?
This is a buffer overrun vulnerability. An attacker who successfully exploited this vulnerability could gain complete control over an affected web server. This would give the attacker the ability to take any desired action on the server, including changing web pages, reformatting the hard drive or adding new users to the local administrators group. The vulnerability could only be exploited if a particular system component is present on the system - one that security checklists and tools recommend be removed. Nevertheless, this is a serious vulnerability, and Microsoft recommends that web server administrators take action immediately.

What causes the vulnerability?
The vulnerability is the result of an unchecked buffer in an ISAPI Extension associated with Index Server in Windows NT 4.0 and Indexing Service in Windows 2000. By sending a specially constructed request to the ISAPI extension, an attacker could cause code to run on a web server in Local System context.

What are Index Server and Indexing Service?
Index Server 2.0 and Indexing Service are full-text search and indexing engines for use with Windows NT 4.0 and Windows 2000, respectively. They provide the ability to search data on a web site or a server. This lets users with a web browser search for documents by entering keywords, phrases or properties. Index Server 2.0 does not ship as part of Windows NT 4.0, but rather is available as part of the Windows NT 4.0 Option Pack. Indexing Service is a native service in Windows 2000, and ships as part of the platform

What's an ISAPI Extension?
ISAPI (Internet Services Application Programming Interface) is a technology that enables developers to extend the functionality provided by an IIS server. An ISAPI extension is a dynamic link library (.dll) that uses ISAPI to provide a set of web functions above and beyond those natively provided by IIS. When a user needs to use one of the functions that an ISAPI extension exposes, they send a request to the server. It's possible in some cases to call an ISAPI extension directly, but it's more common for users to request files on the server that contain commands to be processed. When a user requests such a file, IIS determines which ISAPI extension should be used to parse the file by consulting a table of script mappings that list the file extensions associated with each ISAPI extension on the server.

Which ISAPI extension is associated with this vulnerability?
The ISAPI extension that contains the vulnerability is idq.dll, which provides two types of functions:

  • It provides support for Internet Data Administration (.ida) files, which are scripts that can be used to manage the indexing service. This capability is rarely used, as the Microsoft Management Console provides a better administrative interface.
  • It processes Internet Data Query (.idq) files, which are used to implement custom searches.

What's wrong with idq.dll?
There is an unchecked buffer in a part of the code that handles incoming requests. If a specially malformed request were sent to it, a buffer overrun would result, with either of two results:

  • If the request contained random data, it would cause the web services on the server to fail. If IIS 4.0 were in use on the server, the administrator could resume normal operation by restarting the service; if IIS 5.0 were in use, the web service would automatically restart itself.
  • If the request contained specially selected data, it could be used to cause code of the attacker's choice to run on the server.

If the attacker exploited the vulnerability to run code on the server, what security context would it run in?
It would run with Local System privileges. The effect of exploiting the vulnerability would effectively be to modify idq.dll while it was running; because idq.dll runs as part of the operating system, so would the attacker's code.

What would this enable the attacker to do?
An attacker who exploited this vulnerability would gain complete control over the web server. This would enable to him to take any desired action, including but not limited to:

  • Changing web content
  • Executing operating system commands
  • Reconfiguring the server
  • Loading additional software onto the server and executing it.

Would exploiting the vulnerability give the attacker complete control over an entire network?
Best practices would help limit the scope of the compromise. Because of their exposed position, web servers - especially public ones - are always special targets for attack, and the network design should reflect this fact. Indeed, one of the network architect's principal objectives should be to ensure that the network design limits what could be done using a compromised web server. Two practices in particular that should be followed are:

  • Web servers should be isolated within a DMZ. This not only separates the servers from the Internet, but also separates them from the rest of the network.
  • If possible, web servers should be configured as stand-alone machines. If it's absolutely necessary to make them part of a domain, the domain should only encompass machines that reside on the DMZ. Web servers should never be members of the larger network's domain.

Even if these precautions have been followed, however, it is important not to underestimate the damage that could be done via this vulnerability. Even if the network design denied the attacker an easy means of using normal system operations to extend her control, she could nevertheless use the compromised server as a launching point from which she could try to attack additional machines via other known vulnerabilities.

Who could exploit this vulnerability?
To exploit the vulnerability, an attacker would only need the ability to levy a request upon idq.dll. As long as the script mappings that associate .idq and .ida files with idq.dll were present, and the attacker were able to establish a web session with the server, he could exploit the vulnerability.

Would Index Server or Indexing Service need to be running in order for the vulnerability to be exploited?
No. Although the functionality provided by idq.dll supports Index Server and Indexing Service, the .dll is installed whenever IIS is installed, and is exposed anytime IIS is running. Thus, even if indexing were not available on the server, the vulnerability would still be present as long as IIS were running on the machine.

So, if IIS is not running on my machine, I'm not affected by the vulnerability?
That's correct. Even if you've installed Index Server or Indexing Service, the vulnerability could only be exploited if IIS were running.

I thought .ida files were administrative scripts. Shouldn't the attacker need to be an administrator to levy a request for an .ida file?
Idq.dll does check the credentials of the person requesting an .ida file before processing any of the commands in it. However, the buffer overrun occurs before this check can be made. As a result, any user could request an .ida file and exploit the vulnerability. Even if this were not the case, .idq files typically can be requested by any user.

I followed the IIS Security Checklists, and disabled the script mappings for .ida and .idq files. Am I vulnerable?
If the script mappings for .ida and .idq files aren't present, the vulnerability cannot be exploited. The IIS 4.0 and IIS 5.0 Security Checklists provide instructions for doing this. In addition, the Windows 2000 Internet Server Security Tool will remove the mapping unless you explicitly request that it be retained. However, it is important to note that it is possible for the mapping to be reinstated. Specifically, anytime Windows components are added or removed using the "Add/Remove Programs" applet in Control Panel, Windows performs a system reconfiguration that reinstates both the .idq and .ida mapping. As a result, we recommend that even customers who have removed the mapping apply the patch as a safeguard.

I'm running Windows NT 4.0. Am I vulnerable?
Default installations of Windows NT 4.0 are not vulnerable. IIS 4.0 does not install as part of Windows NT 4.0 - it must be installed via the Windows NT 4.0 Option Pack. However, if you have installed IIS 4.0 you are vulnerable, as Idq.dll is installed as part of the IIS 4.0 installation process.

I'm running Windows 2000 Server. Am I vulnerable?
Default installations of Windows 2000 Server are vulnerable. IIS 5.0 installs by default as part of Windows 2000 server products, and Idq.dll is installed as part of the IIS 5.0 installation process.

If I'm running Windows 2000 Professional, am I vulnerable?
Default installations of Windows 2000 Professional are not vulnerable. In contrast to Windows 2000 Server, IIS 5.0 does not install as part of Windows 2000 Professional. However, if you have installed IIS 5.0 you are vulnerable, as Idq.dll is installed as part of the IIS 5.0 installation process.

What does the patch do?
The patch eliminates the vulnerability by instituting proper input checking in the ISAPI extension.

I heard that Windows XP is vulnerable but there isn't a patch. Is this true?
Versions of Windows XP prior to Release Candidate 1 are affected by the vulnerability. Like all beta products, it should only be used for evaluation purposes, and shouldn't be installed on production servers. The vulnerability has been eliminated in Windows XP Release Candidate 1, and not be present in any subsequent versions, including the final released version of the product. There are a small number of customers who, working closely with Microsoft, are doing limited production deployments using affected versions of the Windows XP beta. Microsoft has contacted these customers directly and provided them with an updated build that eliminates the vulnerability.

Patch availability

Download locations for this patch

Additional information about this patch

Installation platforms:

  • The Windows NT 4.0 patch can be installed on Windows NT 4.0 Service Pack 6a.
  • The Windows NT Server 4.0 Terminal Server Edition Security Rollup Package can be installed on Windows NT 4.0 Terminal Service Edition Service Pack 6.
  • The Windows 2000 patch can be installed on Windows 2000 Gold, Windows 2000 Service Pack 1 or Service Pack 2.

Inclusion in future service packs:

The fix for this issue will be included in Windows 2000 Service Pack 3.

Superseded patches:

  • The Windows NT Sever 4.0, Terminal Server Edition Security Roll-up Package supersedes the patches provided in the following security bulletins:

Verifying patch installation:

Windows NT 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\Q300972.

  • To verify the individual files, consult the file manifest in Knowledge Base article Q300972.

Windows NT 4.0 Terminal Server Edition:

  • To verify that the Windows NT Server 4.0, Terminal Server Edition Security Rollup Package 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\Q317636.

Windows 2000:

  • 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\Q300972.

  • 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\Q300972\Filelist

Caveats:

While removing the .ida and .idq script mappings can protect against this vulnerability, it is possible for these mappings to be reinstated by the system, as discussed in the FAQ. Microsoft recommends that customers who have removed these mapping apply the patch as a safeguard.

Localization:

Localized versions of this patch are available from the download locations listed in the section titled "Patch Availability".

Obtaining other security patches:

Patches for other security issues are available from the following locations:

  • Security patches are available from the Microsoft Download Center, and can be most easily found by doing a keyword search for "security_patch".
  • Patches for consumer platforms are available from the WindowsUpdate web site.

Other information:

Acknowledgments

Microsoft thanks eEye Digital Security (https://www.eeye.com) for reporting this issue to us and working with us to protect customers.

Support:

  • Microsoft Knowledge Base article Q300972 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 (June 18, 2001): Bulletin Created.
  • V1.1 (June 18, 2001): List of superseded patches corrected to indicate that MS00-006 and MS01-025 are not superseded by the one provided in this bulletin.
  • V1.2 (August 06, 2001): Updated specific beta information for Windows XP.
  • V1.3 (August 20, 2001): Patch Availability section updated to indicate that the patch provided here has been superseded by the one provided in MS01-044.
  • V1.4 (August 21, 2001): Released a version of the patch that can be installed on all Windows 2000 versions, including Gold, and updated Installation Platforms section to match.
  • V1.5 (May 6, 2002): Bulletin updated to advise availability of Windows NT 4.0 Server, Terminal Server Edition Security Rollup Package.
  • V1.6 (November 04, 2003): Updated links to Windows Update in Additional Information.

Built at 2014-04-18T13:49:36Z-07:00