|
Brought to you by:
Suppliers of:
|
|
|
| |
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 exists in idq.dll. This 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. |
| |
Credit:
The information has been provided by Microsoft Product Security.
|
| |
Affected Software:
* Microsoft Index Server 2.0
* Indexing Service in Windows 2000
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, can be automatically removed via either the High Security Template or 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.
Patch availability:
Download locations for this patch
* Windows NT 4.0:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=30833
* Windows 2000 Professional, Server and Advanced Server:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=30800
* Windows 2000 Datacenter Server:
Patches for Windows 2000 Datacenter Server are hardware-specific and available from the original equipment manufacturer.
* Windows XP beta:
The vulnerability will be eliminated in the next beta update as well as the final, released version of the product.
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 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 is possible in some cases to call an ISAPI extension directly, but it is 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 an especially 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 is 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 is correct. Even if you have 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 are not present, the vulnerability cannot be exploited. The IIS 4.0 and IIS 5.0 Security Checklists provide instructions for doing this. In addition, the High-Security Template provided in the IIS 5.0 Security Checklist will remove the mapping. Likewise, 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 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, 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 is not a patch. Is this true?
Yes. Windows XP is affected by the vulnerability. However, Windows XP is a beta product and, like all beta products, should only be used for evaluation purposes. It should not be installed on production servers. The vulnerability will be eliminated in the next beta update, and will be eliminated in the final released version of the product.
There are a small number of customers who, working closely with Microsoft, are doing limited production deployments of the current beta version of Windows XP. Microsoft has contacted these customers directly and provided them with an updated build that eliminates the vulnerability.
|
|
|
|
|
