Malformed URL can cause Service Failure in IIS 5.0 and Exchange 2000
10 Mar. 2001
Summary
IIS 5.0 and Exchange 2000 suffer from a vulnerability that enables remote attackers to launch a denial-of-service attack against the IIS or Exchange service.
Credit:
The information has been provided by Kevin Kotas of eSecurityOnline.com.
IIS 5.0 contains a flaw affecting the way that an URL is handled if it has a specific construction and its length is within a very narrow range of values. If such a URL were repeatedly sent to an affected system, a confluence of events could cause a memory allocation error that would result in the failure of the IIS service.
Exchange 2000 is affected by the same vulnerability. To support web-based mail clients, it introduces the ability to address items on the store via URLs. This is done in part by using IIS 5.0, and in part via code that is specific to Exchange 2000. Both pieces of code contain the flaw, but the effect of exploiting the vulnerability via either would be the same - it could be used to cause the IIS service to fail, but could not be used to attack the Exchange service itself.
That is, successfully attacking an Exchange server via this vulnerability would disrupt web-based mail clients' use of the server, but not that of MAPI-based mail clients like Outlook.
Because the flaw occurs in two different code modules, one of which installs as part of IIS 5.0 and both of which install as part of Exchange 2000, it is important for Exchange 2000 administrators to install both the IIS and Exchange patches.
Mitigating Factors:
- The vulnerability would not enable the attacker to gain any administrative control over the server, or to alter any data on it.
- The affected services automatically restart in the event of a failure, so an affected system would resume service almost immediately.
- A successful attack against an Exchange server would only disrupt web-based mail clients' use of the server. The server would continue to be available for MAPI-based clients like Outlook.
- The ISAPI involved in this vulnerability authenticates the user prior to servicing the request, so a properly configured Exchange server would be at less risk than an IIS server.
