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.