Microsoft Security Bulletin (MS00-030): Frequently Asked Questions
What's this bulletin about?
Microsoft Security Bulletin MS00-030 announces the availability of a patch that eliminates a vulnerability in Microsoft® Internet Information Server. Microsoft is committed to protecting customers' information, and is providing the bulletin to inform customers of the vulnerability and what they can do about it.
What's the scope of the vulnerability?
This is a denial of service vulnerability. If a malicious user requested a file from a web server via an URL containing specially-malformed file extension data, the server could become unresponsive for some period of time.
There is no capability via this vulnerability to cause a server to fail, to cause any data to be lost, or to usurp administrative control of the machine. The vulnerability simply provides a way for a malicious attacker to consume most or all CPU availability. Given enough time, the server would resume normal operation on its own.
What causes the vulnerability?
The vulnerability results because of the way that file extensions are handled in IIS. By providing an URL with a particular type of malformed extension, it would be possible to make the algorithm that processes the URL operate very inefficiently. In the worst case, 100% of the CPU availability might be put toward this task, delaying the server's response to legitimate service requests.
What's the problem with how IIS handles extensions?
IIS handles file extension data correctly. It correctly identifies all file extensions, no matter where in the URL they occur, and is fully compliant with the requisite industry specifications. However, the algorithm that parses file extensions can be misused by providing an URL with an extremely large amount of superfluous extension data.
I thought file extensions were pretty simple - just a period followed by three letters. What's the "superfluous extension data" at issue here ?
As most commonly used, a file extension consists of a period followed by three letters and comes at the end of a filename or URL. However, that's not the only way extension data can be used. There's considerable flexibility regarding how and where extensions can be used, especially within an URL. In theory it would be acceptable for an URL to contain multiple extensions located throughout the URL, e.g., http://www.microsoft.com/folder1.vti/folder2.doc/file.txt.zip. Each of the extensions might tell the server how the data in a particular folder or file should be processed, and in what order.
The "superfluous extension data" at issue here is bogus file extension data that's inserted into an URL simply for the purpose of forcing the algorithm to spend time parsing it. As currently implemented, the work factor increases non-linearly with the complexity of the URL. By deliberately sending a highly-complex URL with an extremely large amount of bogus file extension data, a malicious user could arbitrarily increase the load on the server to the point where it no longer performed useful work.
When you say a "highly complex" URL, how complex do you mean?
In order to drive the work factor sufficiently high, an URL would need to be many thousands of characters long, and contain an enormous amount of file extension data. Clearly, this is not a situation that is likely to occur in normal use.
What would be the effect of an attack via this vulnerability?
An attack via this vulnerability would slow the server's response or stop it altogether, but it would not cause the server to fail, nor would it cause any data loss. As soon as the server completed parsing the URL, processing would return to normal. However, a malicious user could repeatedly send such URLs, in an effort to tie up the server indefinitely.
Is there any way, short of installing the patch, to prevent these attacks?
Yes. Administrators can limit the length of the URLs their servers will accept. This has the effect of limiting how complex the URLs can be. . Just set the following registry entry to the maximum-length URL (plus HTTP headers) you want to accept. For more information, see Microsoft Knowledge Base article 260694)
Hive | HKEY_LOCAL_MACHINE \SYSTEM |
Key | CurrentControlSet\Services\W3SVC\Parameters |
Name | MaxClientRequestBuffer |
Value Type | DWORD |
Are IIS 4.0 and IIS 5.0 servers equally vulnerable to such an attack?
No. By default, IIS 5.0 servers would be less likely to be affected than IIS 4.0 servers, because the default maximum length for a URL is significantly smaller in IIS 5.0 than in IIS 4.0. This would have the effect of limiting the complexity of the URL.
Could this vulnerability be exploited accidentally?
It is extremely unlikely that this vulnerability could be exploited accidentally. To drive the work factor sufficiently high to cause the server to slow down, the URL would need to be many thousands of characters long, with a huge amount of file extension data embedded in it, arranged solely to make parsing it as inefficient and difficult as possible.
What does the patch do?
The patch does two things:
| • | It causes IIS to treat an URL as invalid if it contains an extension associated with an executable file type (e.g., .com, .exe, etc.) as part of a directory name. |
| • | It establishes a limit on the total number of dot characters that can be contained in a valid URL. As discussed in the Knowledge Base article, this limit is configurable via a registry value. |
Where can I get the patch?
The download location for the patch is provided in the "Patch Availability" section of the security bulletin
How can I tell if I installed the patch correctly?
The KB article 260205 provides a manifest of the files in the patch package. The easiest way to verify that you've installed the patch correctly is to verify that these files are present on your computer, and have the same sizes and creation dates as shown in the KB article.
What is Microsoft doing about this issue?
| • | Microsoft has developed a patch that eliminates the vulnerability. |
| • | Microsoft has provided a security bulletin and this FAQ to provide customers with a detailed understanding of the vulnerability and the patch. |
| • | Microsoft has sent copies of the security bulletin to all subscribers to the Microsoft Product Security Notification Service, a free e-mail service that customers can use to stay up to date with Microsoft security bulletins. |
| • | Microsoft has issued a Knowledge Base article 260205 explaining the vulnerability and patch in more detail. |
Where can I learn more about best practices for security?
The Microsoft TechNet Security web site is the best to place to get information about Microsoft security.
How do I get technical support on this issue?
Microsoft Technical Support can provide assistance with this or any other product support issue.
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.
