What's the scope of the vulnerability?
This is a denial of service vulnerability. It could enable an attacker to temporarily disrupt service on an affected web, or to temporarily disrupt web-based access to an affected mail server. Although the server in either case would automatically resume normal operation, any sessions in progress at the time of the attack would be lost. The vulnerability does not provide any opportunity for the attacker to usurp administrative control over the server, or to add, change or delete data on it.
What causes the vulnerability?
The vulnerability results because Internet Information Services (IIS) 5.0 and Exchange 2000 do not correctly handle an URL that has a specific construction and a length that falls within a very narrow range of values. If either product received such an URL a sufficient number of times, the IIS service would fail.
I thought URLs were only used in conjunction with web browsing. Why is Exchange affected by this vulnerability?
Exchange 2000 supports the use of web-based mail clients and, as a result, it has the ability to accept and process URLs. In fact, all requests to an Exchange server can be made via URLs. Although the code in Exchange that processes URLs is separate from the IIS code, both have the same flaw.
What's wrong with the URL at issue here?
There's nothing wrong with the URL per se. Although it would be extremely unlikely to ever be sent for a legitimate purpose, both IIS and Exchange should nevertheless be able to deal with the URL and handle it appropriately. Instead, the flaws causes a memory allocation error which, if it occurred enough times, would cause an access violation. This would cause the IIS service on the machine to fail.
Don't you mean that it would cause the IIS or Exchange service to fail, depending on the type of server?
No. In both cases, the effect would be to cause the IIS service to fail. The Exchange service can't be made to fail via this vulnerability.
What would be the effect of a successful attack via this vulnerability?
It would depend on whether the attack was against a web server or a mail server. In either case, it would cause the IIS 5.0 service to fail. On a web server, this would prevent the server from providing web services. On a mail server, it would only prevent web-based mail clients from using the system; mail clients like Outlook, which don't operate via the web, wouldn't see any disruption in their mail service.
Would sending the URL one time cause the service to fail?
No. Not only would the attacker need to pick an URL with the correct construction and length, he'd also need to send it repeatedly in order to exploit the vulnerability.
How long would the disruption last?
Under normal conditions, an attack could only cause a momentary disruption in service. The IIS 5.0 service is configured by default to automatically restart itself in the event of a failure, so it would almost immediately resume normal operation.
Could the vulnerability be used to take over a server?
No. It's strictly a denial of service vulnerability. It could not be used to gain any administrative control over a web or mail server, or change any of the data on it. It could only be used to prevent a server from providing service.
Could the vulnerability be exploited accidentally?
No. It's extremely unlikely that an URL with the particular construction and length could be sent accidentally.
Does this vulnerability pose a greater risk to IIS or Exchange servers?
If best practices have been followed, Exchange servers would be at less risk. Due to the way the affected components are designed, only authenticated users would be able to send requests to the Exchange server under normal conditions. This means that Internet users would be unable to attack an affected Exchange server. In contrast, web servers typically accept requests from any user.
Does this vulnerability affect previous versions of IIS or Exchange?
No. Only IIS 5.0 and Exchange 2000 are affected.
What does the patch do?
The patch eliminates the vulnerability by causing the URL to be appropriately handled. In most cases, such an URL would be invalid, and the patch causes IIS 5.0 and Exchange 2000 to treat it that way.
Why do both the Exchange and IIS patches need to be applied to Exchange 2000 servers?
Although IIS 5.0 and Exchange 2000 contain the same coding flaw, it lies in two different components. One of these components is part of IIS 5.0, and the other is part of Exchange 2000. However, IIS is installed as part of Exchange 2000, so an Exchange 2000 server will require both the IIS 5.0 and Exchange 2000 patches.
